Eclipse Community Forums: EclipseLink » ConcurrentModification Exception in JPA 3.0

Home » Eclipse Projects » EclipseLink » ConcurrentModification Exception in JPA 3.0(Has anyone seen this exception in JPA 3.0)

ConcurrentModification Exception in JPA 3.0 [message #1840006]

Sun, 04 April 2021 05:57

Eclipse User

Hi:
I am working on a large Swing application using a JAVA SE connection through EclipseLink JPA to out H2 database.
We are currently using a very old version of EclipseLink and are trying to upgrade and are seeing this:

jakarta.persistence.PersistenceException: java.util.ConcurrentModificationException
at org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:493) ~[eclipselink.jar:3.0.1-SNAPSHOT]

...
Caused by: java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1493) ~[?:?]
at java.util.HashMap$KeyIterator.next(HashMap.java:1516) ~[?:?]
at org.eclipse.persistence.indirection.IndirectSet$1.next(IndirectSet.java:524) ~[eclipselink.jar:3.0.1-SNAPSHOT]
at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.next(InterfaceContainerPolicy.java:346) ~[eclipselink.jar:3.0.1-SNAPSHOT]

This may very well be some way which we are using JPA. I just want to know if anyone has seen this sort of thing before and what the possible cause might be.
I can see from the logs that a number of calls to JPA do succeed before this exception is thrown.

Thanks for any help.

Re: ConcurrentModification Exception in JPA 3.0 [message #1840031 is a reply to message #1840006]

Mon, 05 April 2021 12:20

Eclipse User

Are you using read-only objects and modifying them in the application? The stack seems to indicate it is going through an iterator to build managed copies of what is in the shared cache while some other thread is modifying it - EclipseLink has cache locks to prevent its updates from causing this sort of behavior, so I would look at what the application is doing first. The stack trace and knowing what object is involved in this query might help you look at the model and figure out which relationship might be using an IndirectSet ( Set implementation for lazy relationships) and find the caller doing the modification, and then ensure it works on a copy instead of the shared object directly.

Re: ConcurrentModification Exception in JPA 3.0 [message #1840035 is a reply to message #1840031]

Mon, 05 April 2021 17:36

Eclipse User

If by read-only you mean something annotated with the

@ReadOnly
annotation.

No. I don't see any entity classes with that.
And we also don't use any READ_ONLY query hints.

Or did you mean something else when you said read-only?

[Updated on: Mon, 05 April 2021 18:23] by Moderator

Re: ConcurrentModification Exception in JPA 3.0 [message #1840107 is a reply to message #1840035]

Tue, 06 April 2021 18:48

Eclipse User

Hello Chris Delahunt:
Thank you for your reply to my issue. I may have fixed this. At least, I am not now seeing the exceptions.

Going on what you said about the cache I commented out this query hint in a class one of our developers wrote that does all the database queries:

query.setHint( QueryHints.REFRESH_CASCADE, CascadePolicy.CascadeAllParts );

The database that backs our application is not of the greatest design. And I think we overdid the annotated relationships. So, what we have are a lot of circular relationships between classes. Multiple entity classes have a relationship of some sort to the SiteHost entity, for example.

I'm guessing that the issue might be multiple threads trying to refresh the same entity, or collection of entities in the cache at the same time because of the query hint to refresh all the dependencies. Does that sound like a possibility?

Re: ConcurrentModification Exception in JPA 3.0 [message #1840871 is a reply to message #1840107]

Tue, 27 April 2021 12:43

Eclipse User

My comments on read-only were to have you check that you aren't getting entity objects from the shared cache and rule out sharing those objects amongst threads as being part of the issue. If you are not setting that or finding query hints, annotations, properties or even descriptor customizers that hint at it (there quite a few ways ways to do it for a class), it seems likely you might be using the same Entity instance read in from one EntityManager among different threads. The refresh cascade setting would cause refreshes to trigger when lazy relationships are triggered, cascading throughout the object graph at different times, not just when the initial query executes. If you have multiple access points querying to different parts of the same root node(s) using that hint, it might force them to be refreshed multiple times. If just removing that setting and using refresh less liberally works to reduce/remove the occurrences of that error, it means that what you described, multiple threads refreshing the same entity graph structure at the same time - but it doesn't mean that EclipseLink's refresh is what is modifying the list, it could be your application itself. The refresh is just one process that must iterate over collection mappings and would hit the issue, but we don't see the thread/process that is modifying the list to know what others are involved. I don't know if you want to go looking to see if those threads are using the same EntityManager instance, as I suspect they must be somehow if the object with the IndirectSet getting the exception wasn't from the shared cache (via a read-only setting).

Best Regards,
Chris

Previous Topic:	DYNAMIC ENTITY SERIALIZATION ISSUE
Next Topic:	OneToMany - org.eclipse.persistence.exceptions.DatabaseException

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Nov 07 16:58:05 EST 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter