You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Colin Kilburn <co...@accesstec.ca> on 2005/09/08 22:05:56 UTC

ImplicitLocking clarification / confusion

Hello,

I'm using OJB 1.0.3 with the ODMG api and I'm confused about implicit 
locking.   I prefer from past experience to have ImplicitLocking=false 
in my OJB.properties and this is what I've done for quite some time.

I've started getting (sometimes) LockNotGrantedExceptions on objects 
that I haven't explicitly locked -- i.e. I lock a new object for write, 
and despite having implicit locking set to false, ojb attempts to aquire 
a write lock on a referenced object that hasn't changed (otherwise I'd 
have explicitly locked it).   The stack trace below shows the failure on 
User, which is referenced by the new record:

org.odmg.LockNotGrantedException: Can not lock for WRITE: 
ca.accesstec.acsis.core.security.User{1}
    at 
org.apache.ojb.odmg.TransactionImpl.doSingleLock(TransactionImpl.java:319)
    at 
org.apache.ojb.odmg.TransactionImpl.lockAndRegister(TransactionImpl.java:263)
    at 
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertSingleReferences(ObjectEnvelopeTable.java:601)
    at 
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertFor(ObjectEnvelopeTable.java:561)
    at 
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeMarkedForInsert(ObjectEnvelopeTable.java:541)
    at 
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadingDependents(ObjectEnvelopeTable.java:510)
    at 
org.apache.ojb.odmg.ObjectEnvelopeTable.writeObjects(ObjectEnvelopeTable.java:169)
    at 
org.apache.ojb.odmg.TransactionImpl.doWriteObjects(TransactionImpl.java:370)
    at 
org.apache.ojb.odmg.TransactionImpl.prepareCommit(TransactionImpl.java:687)
    at org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:623)

Can someone kindly explain this to me?  or at least suggest how I can 
tell OJB to only write-lock objects for which I call 
Transaction.lock()?  I have traced through this and don't see why 
ObjectEnvelopeTable needs to do a cascadingDependents().

Could the real problem be somewhere else?  

Many thanks in advance,
Colin

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org


Re: ImplicitLocking clarification / confusion

Posted by Armin Waibel <ar...@apache.org>.
Hi Colin,

 > Can someone kindly explain this to me?

Well! Good question ;-)
The current definition for 'implicit locking' only include objects 
returned by oql-queries. These objects will not be locked.

Your problem is caused by "overeager" object state detection. On 
insert/update of objects OJB try to find new/changed/deleted referenced 
objects. In your case OJB find a 1:1 referenced object.
Think you found a bug, because OJB should only register/lock new 1:1 
referenced objects, if the referenced object needs update it has to be 
already registered/locked (by implicit locking or by user).


 >  or at least suggest how I can
 > tell OJB to only write-lock objects for which I call
 > Transaction.lock()?

With implicit locking 'false' only the specified object will be locked, 
references will be ignored (no recursive locking).
For new/changed objects detected by OJB it's currently not possible to 
disable automatic register/lock of these objects to prevent unexpected 
behavior. But in your case this will never happen, because you already 
locked all new/changed objects.

I checked in a patch. If possible please patch ObjectEnvelopeTable by 
yourself by replacing
line 509
if(depMod == null)
with
if(depMod == null && rt.isNew())

or check out latest version from CVS (OJB_1_0_RELEASE branch).
Does it resolve your problem?


 >  I have traced through this and don't see why
 > ObjectEnvelopeTable needs to do a cascadingDependents().
 >

This is a main part of object state detection. It is responsible to 
detect new/deleted objects in the references of the main object, e.g. 
when the user move a 1:n referenced object B from object A to object A'.

regards,
Armin


Colin Kilburn wrote:
> Hello,
> 
> I'm using OJB 1.0.3 with the ODMG api and I'm confused about implicit 
> locking.   I prefer from past experience to have ImplicitLocking=false 
> in my OJB.properties and this is what I've done for quite some time.
> 
> I've started getting (sometimes) LockNotGrantedExceptions on objects 
> that I haven't explicitly locked -- i.e. I lock a new object for write, 
> and despite having implicit locking set to false, ojb attempts to aquire 
> a write lock on a referenced object that hasn't changed (otherwise I'd 
> have explicitly locked it).   The stack trace below shows the failure on 
> User, which is referenced by the new record:
> 
> org.odmg.LockNotGrantedException: Can not lock for WRITE: 
> ca.accesstec.acsis.core.security.User{1}
>    at 
> org.apache.ojb.odmg.TransactionImpl.doSingleLock(TransactionImpl.java:319)
>    at 
> org.apache.ojb.odmg.TransactionImpl.lockAndRegister(TransactionImpl.java:263) 
> 
>    at 
> org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertSingleReferences(ObjectEnvelopeTable.java:601) 
> 
>    at 
> org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertFor(ObjectEnvelopeTable.java:561) 
> 
>    at 
> org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeMarkedForInsert(ObjectEnvelopeTable.java:541) 
> 
>    at 
> org.apache.ojb.odmg.ObjectEnvelopeTable.cascadingDependents(ObjectEnvelopeTable.java:510) 
> 
>    at 
> org.apache.ojb.odmg.ObjectEnvelopeTable.writeObjects(ObjectEnvelopeTable.java:169) 
> 
>    at 
> org.apache.ojb.odmg.TransactionImpl.doWriteObjects(TransactionImpl.java:370) 
> 
>    at 
> org.apache.ojb.odmg.TransactionImpl.prepareCommit(TransactionImpl.java:687)
>    at org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:623)
> 
> Can someone kindly explain this to me?  or at least suggest how I can 
> tell OJB to only write-lock objects for which I call 
> Transaction.lock()?  I have traced through this and don't see why 
> ObjectEnvelopeTable needs to do a cascadingDependents().
> 
> Could the real problem be somewhere else? 
> Many thanks in advance,
> Colin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org