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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
