Hi, I'm using Hibernate 4.0.1 via JPA2 and have an Entity (portfolio) with a collection of entries as follows:


I understand that when this entity is created by Hibernate, the map instance is actually a PersistentMap, and not a ConcurrentHashMap. As such, it doesn't support modification while it is being persisted (throws a ConcurrentModificationException as I believe it uses a java.util.HashMap underyling)

Is there any way to have Hibernate use a concurrent modification safe map as the underlying? My application makes rapid changes to the collection on the main application thread, while performing persistence of the entity on a background thread. Given the time taken to persist (merge actually), there are sometime new changes during persistence, which is the issue. I don't have an issue with the persistence lagging behind the live object since the persist operations are queued.

One option is to copy the collection on the background thread and persist the copy. That would work okay, but I'm just wondering if there's a more efficient solution. I'm very much a Hibernate/JPA novice so any advice would be appreciated. In case it's relevant, the entity is always detached after merge.

One thing I tried was:
- fetch the entity from the DB
- construct a new entity object explicitly (i.e. new) so that the map instance is a ConcurrentHashMap
- copy the data from the DB object to the manually created Entity
- use that object in the app and persist it

This led to a different ConcurrentModificationException, this time during commit rather than merge:


Thanks

Hi,

hibernate is as documented not thread-safe.
Working with 2 threads simultaneusly on objects which belong to the same session
usually creates race conditions with unpredictable behaviour and exceptions of various types.
Your approach is rather uncommon and dangerous.

Why do you can't do the persistence task flush/commit in your main thread?
If you can flush/commit rather rarely, then it should not influence your through-put that much.



I don't believe it exist.




I think that's a clean and therefore good solution.
I you still have performance problems with such approach,
then I think you have some ask yourself if you can change something in the architekture of the whole thing.

Hi, thanks for your reply.

The issue with persisting on the main thread is latency. Total throughput isn't really an issue since writes are not that frequent, but unfortunately the main thread can't afford to be delayed by the few milliseconds it takes to persist.

The entity is not managed. For what it's worth, I ended up implementing the copy approach.

I now have a @Transient ConcurrentHashMap and a persisted HashMap. The transient map is populated in a @PostLoad method (needed to upgrade hibernate version to avoid issue HHH-6043 - https://hibernate.atlassian.net/browse/HHH-6043).

Any changes to the livePositions map are put into a ConcurrentLinkedQueue and during persistence operations, the background thread simply processes any items in the queue to bring the positions map up to date prior to persisting.

Then probably you have also to configure an appropriate Garbage Collector causing only minimal pauses...

Correct. I use the concurrent low pause collector with an optimized initial heap size and a few other tunings.