1 Reply Latest reply on Oct 28, 2013 4:04 AM by Horia Chiorean

    How to create a unique parent with concurrent writers

    Jonathan Fields Novice

      I'm not sure that my title is the best, but I think this is a fairly common situation. I have some code that essentially does this:

       

      start tx

      open session

      if /a does not exist create /a (nt:unstructured)

      add a new child to /a (b1, b2, etc)

      save session

      commit tx

       

      I have ISPN lock mode set to PESSIMISTIC. Many threads are calling this concurrently (SLSBs to be exact).

       

      I expected (and would like) to end up a single parent /a and all the child nodes beneath it:

       

      /a/b1

      /a/b2

      ...

       

      But occasionally I end up with multiple SNS parents:

       

      /a/b1

      /a[1]/b2

      /a[2]/b3

       

      I was expecting with PESSIMISTIC locking that this would not occur. Do I need to put a lock around the "if /a does not exist create /a" and put that in a separate session? Do I need to (JCR) lock the root when adding /a?  What's the best way to ensure that when you create only a single parent in a situation like this?

       

      Thanks!

        • 1. Re: How to create a unique parent with concurrent writers
          Horia Chiorean Master

          PESSIMISTIC locking in ISPN will not help you in this case because that only takes place when session.save() is called, which is probably too late. In other words, both T1 and T2 (threads) can/will see "a" as non-existent and add "a" as a child node of the root node and eventually call "session.save()" which in PESSIMISTIC mode will "serialize" the data changes, but both will perform the add.

           

          IMO you need to solve this problem "at a higher level" in your application. I can think of  several ways of doing this (not all may apply given your context):

          • create "a" from a single thread (always)
          • use an intermediate parent under the WS root which doesn't allow SNS and handle the exception
          • use Java locks or some other mechanism to synchronize the part which creates "a"
          • use JCR locks and handle LockException