1 2 Previous Next 25 Replies Latest reply on Mar 26, 2009 12:37 PM by dukehoops

    Lock striping broken for Second Level Cache use case

    Brian Stansberry Master

      The unit test dukehoops has posted on http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151524&start=20 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.

        1 2 Previous Next