-
1. Re: Locking behaviour unclear
aloubyansky Jul 9, 2004 6:05 AM (in response to silviomatthes)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 Jul 9, 2004 6:21 AM (in response to 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 Jul 10, 2004 6:24 AM (in response to silviomatthes)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 Jul 30, 2004 4:40 PM (in response to silviomatthes)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 Aug 11, 2004 9:27 AM (in response to silviomatthes)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 Aug 11, 2004 9:47 AM (in response to silviomatthes)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 Aug 12, 2004 7:13 AM (in response to silviomatthes)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 Oct 5, 2004 11:45 AM (in response to silviomatthes)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 Nov 18, 2004 12:35 PM (in response to silviomatthes)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 Sep 23, 2005 3:12 PM (in response to silviomatthes)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?