"dukehoops" wrote : Ok, I was able to create a multithreaded JUnit test to fail (with just 4 threads). Great! Can you send me that? My address is to the left. anonymous wrote : | I guess the problem lies either with versioning (either Hibernate versioning or MVCC versioning) or (insufficient?) locking. I've think you've exposed a logical flaw with the locking -- either in the hibernate-jbc integration or with the basic design in hibernate core itself. With an entity this kind of thing would not be a problem because a database lock on the record would either 1) block b2 updating the entity until a's tx is done 2) block a1's read until b's tx is done. But with a collection there is no single database record that both tx's need to lock on. anonymous wrote : | You said previously that assumptions around synchronization ordering were fixed for JBossTS and JBC specifically. Was the fix to order synchronizations in TX manager impl? Yes. anonymous wrote : | The reason I ask is that Spring seems to use a Synchronization to close Hibernate Sessions. Is there an expectation that *that* syncrhonization fire *before* JBC's synchronization? If you could give me a link to the Spring code, that would be good. This doesn't sound like a problem though; the key thing is that the session is flushed to the database before JBC's Synchronization's beforeCompletion() is called. Hibernate's own CacheSynchroniztion handles that. Sounds like Spring is calling Session.close() which is a housekeeping operation that would come *after* the above. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215469#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...