[jboss-dev-forums] [Design of JBossCache] - Lock striping broken for Second Level Cache use case

The unit test dukehoops has posted on http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151524&a... is showing the fundamental problem with using lock striping. Eventually you are going to get failures due to deadlocks as different txs acquire different stripes. But with some of the stuff 2LC does, particularly if query caching is enabled and a shared cache is used, the probability is quite high. Assume you have a tx (all Fqns below are for example only): writes to /ENTITIES/Contacts/1 locks a stripe writes to /ENTITIES/Contacts/2 locks a stripe beforeCompletion() by Hibernate and JBC afterCompletion() by Hibernate tries to update the timestamps cache: non-tx write to /TIMESTAMPS/Contacts For sure within a relatively small # of txs, some Fqn /ENTITIES/Contacts/x is going to map to the stripe needed by /TIMESTAMPS/Contacts. Therafter, no tx involving that Fqn is every going to succeed. The test dukehoops submitted runs 200 tx's involving about 205 fqns (plus structure). It fails with the default 500 concurrencyLevel 100% of the time. If I increase concurrencyLevel to 5000, it fails with about 7500 txs, maybe less. There needs to be some sort of lock-per-fqn scheme here. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218836#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...