10 Replies Latest reply on Sep 23, 2005 3:12 PM by ceh

    Locking behaviour unclear

    silviomatthes

      Hallo,

      I'm experiencing a locking behaviour that I do not understand completely.
      I'm using:
      JBoss 3.2.5,
      Commit-Option: A
      locking-policy: QueuedPessimisticEJBLock

      We have 2 EJBs (that are relevant here), user and document.
      document has a field user (to save which user created a document).
      All getter-Methods of user are made read-only and the bean is reentrant.

      When I create a document (in a transaction), in ejbpostcreate() I set the user via document.setuser(user).
      While this tx is running, I cannot access any of the getter methods of this user-Entity.

      When I change the user-bean to read-only, no locking occurs.
      But I want to create users and change them so I cannot use a read-only-bean.


      Now my question is: Is this behaviour of locking the userbean right (and why)?

      Any information would be highly appreciated.

      Silvio

        • 1. Re: Locking behaviour unclear
          aloubyansky

          When you modify one side of the relationship, we have to modify the other one. For that we need a lock. Since you are using pessimistic locking, the lock is pessimistic.
          In read-only case, locking still happends but only for the duration of the method invocation, not the tx.

          • 2. Re: Locking behaviour unclear
            silviomatthes

            Hello Alexey,

            thank you for your answer.

            I understand the lock of the other side (user) if this relation would be bidirectional. But its unidirectional, so from user there is no connection to document.
            So is the lock really needed, even for unidirectional relations?

            Silvio

            • 3. Re: Locking behaviour unclear
              aloubyansky

              Seems like you are right. Theoretically locking the 'blind' side is not required in this case unless the blind side has a foreign key which is modified.

              In fact, uni- and bidirectional relationships are managed in the same way. And the blind side still holds the state of the relationship as part of its persistent state to find out and possibly destroy the existing relationships when we modify it. You could think of it as an architectural bug.

              • 4. Re: Locking behaviour unclear
                philc

                I have been banging my head against this bug for a fews months now. It has heavy repercussions on my application. For example executing a method in seperate transactions on multiple children of a parent in impossible even when the relationship is uni-directional:

                /**
                 * @ejb.transaction
                 * type="Required"
                 */
                public void feedChildren(ParentPK parentPK) {
                 ParentLocal parentLocal = parentHome.findByPrimaryKey(parentPK);
                 Collection children = parentLocal.getChildren();
                 childrenIterator = children.iterator();
                 while (childrenIterator.hasNext()) {
                 child = i.next();
                 feed(child);
                 }
                }
                
                /**
                 * @ejb.transaction
                 * type="RequiresNew"
                 */
                public void feed(ChildPK childPK) {
                 child.setHungry(false);
                }
                


                This code locks until the transaction times out. Replacing the transaction type to NotSupported throws

                java.lang.IllegalStateException: A CMR collection may only be used within the transction in which it was created


                I'm ready to solve this bug. Could you point to the appropriate JBoss module in the source and maybe even specific java source files?

                • 5. Re: Locking behaviour unclear
                  philc

                  Anybody home?
                  Locking blind-side of unidirectional relationships when calling getter method and ignoring read-only tags for relationship methods.
                  I would like to get a brief summary of why this is the way it is?

                  • 6. Re: Locking behaviour unclear
                    philc

                    Woops I pressed Submit too fast...
                    I would also like to know how easy or dificult this is to change. This feature cause lots of deadlock in my application because the related beans get locked everytime a call to getValueObject is processed. (My value objects contain related beans)
                    I realize that this my be due to an architectural decision at the root of the jboss CMP engine and therefore very difficult to change, but I'm ready to spend some time on this. I just need a little direction to do it.

                    Philipppe

                    • 7. Re: Locking behaviour unclear
                      aloubyansky

                      A CMR getter does not lock its value. The instances are locked when you iterate through the CMR collection and invoke methods on instances. This intended behaviour for the standard container configuration.
                      Mark CMP getters as read-only.

                      • 8. Re: Locking behaviour unclear
                        tjodolf

                        So, this would mean that this quote from your documentation is not correct?

                        ”When a bean is marked as read-only, it never takes part in a transaction. This means it is never transactionally locked”

                        • 9. Re: Locking behaviour unclear
                          philc

                          In the situation where 2 transactions set a unidirectional relationship on the same object, the second transaction will lock-up until it timeout. maybe this is the normal CMP behaviour, but it seems like this operation should be possible.

                          The case I'm working on has 2 Tx happen that execute one inside the other. 3 EJBs, Order, Log and Destination
                          Order and Log link to Destination in separate Transactions

                          // Required
                          sendOrder(OrderLocal order, DestinationLocal destination) {
                           order.setDestination(destination);
                           createLog(destination);
                          }
                          
                          // RequiresNew
                          createLog(DestinationLocal destination) {
                           LogLocal log = LogHome.create();
                           log.setDestination(destination);
                          }
                          


                          Destination is blind to Order and Log. But the call to log.setDestination(destination) lock until the transaction times out.

                          As metioned before by loubyansky, this might be an architectural bug. Can it be fixed? Will it be fixed? As it been fixed? (I'm running JBoss3.2.3)

                          loubyansky wrote:
                          You could think of it as an architectural bug.




                          • 10. Re: Locking behaviour unclear
                            ceh

                            Alexy - as this is an architectural bug - I am hamstring by it as well - when will it be fixed/has it been fixed, and if so, in what version of JBoss?