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 St...@fws.gov on 2005/09/23 20:16:29 UTC
ObjectEnvelopeTable: "Unexpected behavior"
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
steve_clark@fws.gov
(970)226-9291
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: ObjectEnvelopeTable: "Unexpected behavior"
Posted by St...@fws.gov.
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
steve_clark@fws.gov
(970)226-9291
Armin Waibel <ar...@apache.org>
09/23/2005 12:51 PM
Please respond to
"OJB Users List" <oj...@db.apache.org>
To
OJB Users List <oj...@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
Steve_Clark@fws.gov 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
> steve_clark@fws.gov
> (970)226-9291
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: ObjectEnvelopeTable: "Unexpected behavior"
Posted by Armin Waibel <ar...@apache.org>.
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
Steve_Clark@fws.gov 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
> steve_clark@fws.gov
> (970)226-9291
>
>
> ---------------------------------------------------------------------
> 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