Armin,
Thanks for the quick response. This patch does fix the error for me.
I'm still confused about why this code is getting called at all - it looks
like there is some implicit locking happening, even though
ImplicitLocking=false. Am I misunderstanding what's going on?
thanks,
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
Armin Waibel <[EMAIL PROTECTED]>
09/23/2005 12:51 PM
Please respond to
"OJB Users List" <ojb-user@db.apache.org>
To
OJB Users List <ojb-user@db.apache.org>
cc
Subject
Re: ObjectEnvelopeTable: "Unexpected behavior"
Hi Steve,
seems I had fixed a bug and introduce another bug - sorry.
> The insert logic is cascading anyway - the exception is thrown when
> cascadeInsertSingleReferences() encounters C, which is not new and is
not
> known to the Transaction. Here's the top of the stack trace:
If C is not new and unknown nothing should happen. Think the code
section throwing the exception should be removed.
So could you try to replace ObjectEnvelopeTable line 589 to 605 with:
if(!alreadyPrepared.contains(oid))
{
ObjectEnvelope depMod = getByIdentity(oid);
// if the object isn't registered and is a new object, register it
// else we have nothing to do
if(depMod == null && rt.isNew())
{
getTransaction().lockAndRegister(rt, Transaction.WRITE, false,
getTransaction().getRegistrationList());
depMod = getByIdentity(oid);
cascadeInsertFor(depMod, alreadyPrepared);
}
}
Then only unregistered new objects will be performed in cascade insert.
Does this solve your problem?
regards,
Armin
[EMAIL PROTECTED] wrote:
> I am using 1.0.4 from CVS as of yesterday. I am getting this exception,
> thrown at ObjectEnvelopeTable line 602 (the comment is the infamous
> "should never occur"). The behavior was introduced in 1.32.2.22 - I
have
> verified that it does not occur in 1.32.2.21.
>
> What is happening is this: I am creating a new object A, which has a
> reference to B, which in turn has a reference to C. I have a write lock
> on A, a read lock on B, and no lock at all on C. ImplicitLocking is
> false.
>
> The insert logic is cascading anyway - the exception is thrown when
> cascadeInsertSingleReferences() encounters C, which is not new and is
not
> known to the Transaction. Here's the top of the stack trace:
>
> java.lang.RuntimeException: Unexpected behavior
> at
>
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertSingleReferences(ObjectEnvelopeTable.java:603)
> at
>
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertFor(ObjectEnvelopeTable.java:556)
> at
>
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertSingleReferences(ObjectEnvelopeTable.java:605)
> at
>
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertFor(ObjectEnvelopeTable.java:556)
> at
>
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertSingleReferences(ObjectEnvelopeTable.java:605)
> at
>
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertFor(ObjectEnvelopeTable.java:556)
> at
>
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeMarkedForInsert(ObjectEnvelopeTable.java:536)
> at
>
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadingDependents(ObjectEnvelopeTable.java:505)
> at
>
org.apache.ojb.odmg.ObjectEnvelopeTable.writeObjects(ObjectEnvelopeTable.java:170)
> at
>
org.apache.ojb.odmg.TransactionImpl.doWriteObjects(TransactionImpl.java:384)
> at
>
org.apache.ojb.odmg.TransactionImpl.prepareCommit(TransactionImpl.java:743)
> at
> org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:679)
>
> Why should cascadingDependents() even be called here? I'm unclear
whether
> 1.32.2.22 introduced the behavior and is therefore wrong, or whether it
> simply exposed some other problem.
>
> thanks,
> -steve
>
> Steve Clark
> ECOS Development Group
> [EMAIL PROTECTED]
> (970)226-9291
>
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
