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]
