Hi,
We encountered some threading issues when a persistent map is used (some how multiple keys are created in the db). What's the best way to synchronize the map in a persistent object? Can I use something like java.util.concurrent.concurrentHashMap?

Thanks,
--Jiunjiun

[b]Hibernate version:[/b]
2.1.7c
[b]Mapping documents:[/b]

[b]Code between sessionFactory.openSession() and session.close():[/b]

[b]Full stack trace of any exception that occurs:[/b]

[b]Name and version of the database you are using:[/b]

[b]The generated SQL (show_sql=true):[/b]

[b]Debug level Hibernate log excerpt:[/b]

that won't help you if you have a session per unit-of-work (which is recommended!)

It sounds like you have another issue - like not having proper constraints on your db or not doing proper existence check before creating a new entity...

Can you explain why it won't work for the session per unit of work scenario?
Is it because hibernate replaces the collection with its own implementation after detach?

As for the constraint, yes, we had add one after we found the problem. The duplicated entry is not a standard alone entity, but an entry in a map<string, string>, which we are relying on the map to guarantee no duplication. In our current case, we are replacing the hash map with jdk 1.5's concurrent hash map.

I probably should mention that we have only one copy of the persistent object (which contains the map) in memory so all the concurrency control is on this object.

I were assuming you had multiple instances of the object since you would get that if you e.g. queried for it before associating it with the querying session....and one object should not be in more than one session at the time or you would get funny race conditions (not saying that it is not doable, it is just harder to maintain)

Regarding having a singleton (as it sounds like this one is) I would either

A: embed the state INSIDE the singleton so it is not the actual singleton you persist - and thus no one can get access to it while persisting...(of course by guarding the state on the singleton)

B: expose thread-safe accessors to the collections and not the core collection it self. Like addX,getX or maybe a getConcurrentXS() which does your trick - but keep a way for hibernate to access the collection "raw", here meaning either have field or private method access....

Thanks for your clarification. I think we have done A. For B, can the core collection you mentioned be a concurrentHashMap so I don't need to write an extra thread-safe accessor? My guessing is it may still be a problem when the persistent state is persisted since the old map may be gone.

well the set that hibernate will return won't be a concurrent-collection...so no