6 Replies Latest reply on Mar 13, 2007 9:39 AM by Manik Surtani

    Distributed lock manager

    Manik Surtani Master

      Referencing this thread and various other discussions.

      Is the subject something we want to implement in JBoss Cache in some shape or form, at some stage?

      I agree that here are scalability issues with such a feature, but is it not fair comment to say that there are use cases where this is critical, our competitors have this in some shape, and it may be a good idea to offer it?

      Specifically looking at a recent support case where each node in a cluster would, within the scope of a tx, read from the cache, increment the value read, and replace the value in the cache. So a write-mostly scenario here. And this would, when used with SYNC_REPL, inevitably deadlock after some while.

      Also, two of our most high-profile competitors - Tangosol and Terracotta - both have some form of distributed locking. Each one implemented differently, but it is there all the same.

      The purpose of this thread is to discuss potential implementations and how this would work with JBoss Cache.

        • 1. Re: Distributed lock manager
          Manik Surtani Master

          I'm thinking of something which can be swapped in place of the Pessimistic/OptimisticLockInterceptor (DistPess/OptLockInterceptors?) which in addition to obtaining local locks, uses a methodcall broadcast to replicate lock() methodcalls up remote stacks.

          Not the most efficient since this will have all sorts of scalability problems, but at least it gives us an initial impl of distributed locking in JBC.

          • 2. Re: Distributed lock manager
            Manik Surtani Master

            Later, more sophisticated mechanisms could include awareness of partitions and buddy groups, and only replicate the lock call to nodes which are known to have the state.

            Also, maybe Terracotta's client-server mechanism for dealing with distributed locks (ugly cos it's client svr) may be more efficient?

            • 3. Re: Distributed lock manager
              Brian Stansberry Master

               

              "manik.surtani@jboss.com" wrote:
              I'm thinking of something which can be swapped in place of the Pessimistic/OptimisticLockInterceptor (DistPess/OptLockInterceptors?) which in addition to obtaining local locks, uses a methodcall broadcast to replicate lock() methodcalls up remote stacks.


              It would be nice to be able to make this more explicit and hence fine-grained. E.g. I have some data structure that maps to a subset of the tree. At the beginning of a tx I call lock("/session/123") which results in a broadcast, but thereafter no other actions I take that send out any cluster-wide messages. Assuming the lock() call results in a WL, the presence of the WL protects the rest of the subtree for the duration of the tx.

              • 4. Re: Distributed lock manager
                Manik Surtani Master

                I'm not a fan of exposing locking behaviour so explicitly. Internally, a sequence of calls like:

                tx.begin();
                cache.put("/session/123");
                cache.put("/session/123/abc")
                cache.put("/session/123/xyz")
                tx.commit();
                


                should result in a single distributed WL obtained during the first put and released at commit.

                I guess your reasoning is how do you deal with this if you don't want to use txs?

                • 5. Re: Distributed lock manager
                  Brian Stansberry Master

                   

                  "manik.surtani@jboss.com" wrote:

                  I guess your reasoning is how do you deal with this if you don't want to use txs?


                  Not really. If we could also get the behavior you describe via any batching API, I think that would be fine. And I think having to use a tx to get that behavior until we have batching is a reasonable short-term limitation.

                  • 6. Re: Distributed lock manager
                    Manik Surtani Master

                    Agreed. Ok, maybe an early impl like that could be quite feasible. Won't be something like Terracotta's intercepting synchronized blocks on the JVM level and performing similar "remote" synchronizations via their "hub", but a more specific scenario focused on locking nodes in the cache based on our existing lock strategies.