It seems like the problem is broader than that. It occurs whenever hibernate wishes to alter cache in Synchronization.afterCompletion() - i.e. whenever Hibernate chooses to execute org.hibernate.action.BulkOperationCleanupAction.evictEntityRegions(). In our specific case this happened against *ENTITY* region because we used hql Query.executeUpdate method. In that case, it seems, Hibernate chooses not to be granular (ie alter/remove only entities affected by the HQL update), but rather to simply evict the entire ENTITY region. Perhaps this will supplement your thinking on http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818
I worked around our specific problem, by ensuring Hibernate does not execute the evict - i.e. by replacing Query.executeUpdate with domain model methods.
I am trying to follow your discussion on lock striping but - thus far - have fairly little understanding of what's going on ;-
Yes, the issue you describe is the core reason for HHH-3818.
To understand the locking discussion you'd need to have a look at the classes in https://svn.jboss.org/repos/jbosscache/core/trunk/src/main/java/org/jboss/cache/util/concurrent/locks/ particularly PerElementLockContainer.
The lock striping issue in general is that instead of having a lock per Fqn, there is a configurable number of shared locks, with Fqn mapping to a shared lock via a hash function. This can introduce lock conflict problems.
dukehoops, I've checked in some fixes for HHH-3817 and HHH-3818 on hibernate's core/trunk/cache-jbosscache2. Included is your MVCCConcurrentWriteTest, although the testManyUsers test is renamed testManyUsersFailureExpected. That naming convention tags a test method as a known failure that won't cause the build to fail. It won't pass until a version of JBC w/ JBCACHE-1494 is released and integrated.