Andrus Adamchik <andru..bjectstyle.org> wrote:
> I really can't tell what's causing it. You are right - the usual cause
> is deletion (directly or via CASCADE delete rules). IIRC there were
> some bugs reported (and fixed) in the past that caused quiet change of
> an object state to transient on certain referential integrity problems.
> I don't think we are doing that anymore.
>
> A few suggestions:
>
> 1. Try it with RC1. [v.1.1-dev April 14 2004] - you have a pretty old
> version (I know, you have your own customizations to the source, so
> upgrade is not always easy).
>
> 2. To debug, override
> com.gvea.cayenne.ebpp.entity.User.setPersistenceState() and do a
> Tread.dumpStack() whenever the new state is TRANSIENT. This way you
> will see where this actually happens.
I had this error happen again under 1.1RC1. I've also had multiple
occurrances of a couple of other unexplained errors that I think are
probably related (one where a datacontext was unexpectedly null).
I've modified my local copy of CayenneDataObject to dump a stack where ever
it seemed possible that the persistent state might be changed to transient.
Hopefully, I'll get to the bottom of the issue the next time it happens.
-Mike
> On Oct 7, 2004, at 4:56 PM, Mike Kienenberger wrote:
>
> > In the year I've been using Cayenne, I've never seen this situation
> > before.
> >
> > Caused by: org.objectstyle.cayenne.CayenneRuntimeException: [v.1.1-dev
> > April
> > 14 2004] Only COMMITTED and HOLLOW objects can be transferred between
> > contexts. Invalid object state 'transient', ObjectId:
> > com.gvea.cayenne.ebpp.entity.User: <USER_ID: 26>
> > at
> > org.objectstyle.cayenne.access.DataContext.localObjects(DataContext.jav
> > a:577)
> > at
> > com.gvea.cayenne.GenericEntity.getLocalObject(GenericEntity.java:113)
> > at [User mySelectedUser = (User)getLocalObject(aDataContext,
> > selectedUser);]
> >
> > selectedUser (<USER_ID: 26>) in this case is an object that's existed
> > in the
> > database for months.
> >
> > How can my DataObject go from a persistent state to 'transient'? I'm
> > 99%
> > sure it had to have been in a COMMITTED state beforehand, with
> > modified or
> > hollow being the other possible 1%. The only way I know this could
> > happen
> > is if the object was deleted (never happens to user objects in this
> > application) or marked invalidated after being modified such that the
> > restricting qualifier made it invisible to the application (my
> > INVALIDATED
> > field was not changed for this record).
> >
> > What's even weirder is that this is the last step in a financial
> > transaction
> > update sequence, so the same user DataObject was just used to create
> > this
> > PAYMENT_HISTORY record, yet failed on the update of the PAYMENT_HISTORY
> > record after the payment processing gateway returned a success/fail
> > status.....
> >
> > // simplified code removing error trapping:
> >
> > aPaymentHistoryObject =
> > aPaymentProcessor.startPaymentHistoryLog(administrativeUser,
> > selectedUser,
> > aDataContext, aPayment, amountToPay);
> > // above includes a commitChanges()
> >
> > Map processPaymentResultDictionary =
> > aPaymentProcessor.processPayment(aPayment, aPaymentHistoryObject,
> > selectedUser);
> >
> > // The line below is where the error occurred.
> > // selectedUser below is now transient according to validation
> > exception!
> > aPaymentProcessor.finishPaymentHistoryLog(administrativeUser,
> > selectedUser,
> > aPaymentHistoryObject, processPaymentResultDictionary);
> >
> >
> > PAYMENT_HISTORY record below created by the first line:
> >
> > ACCOUNT_NUMBER PAYMENT_AMOUNT
> > -------------- --------------
> > 93682 33.13
> >
> > PAYMENT_DATE
> > -----------------------------------------------------------------------
> > ----
> > 07-OCT-04 11.18.10.500000 AM
> >
> > PAYMENT_ID PAYMENT_METHOD_ID R REMOTE REMO REMO REMO
> > REMOTE_TRANSACTION_ID
> > ---------- ----------------- - ------ ---- ---- ----
> > ---------------------
> > 2272 893
> >
> > SCHEDULED_PAYMENT_ID S USER_ID
> > -------------------- - ----------
> > ? 26
> >
> > -Mike
> >
>
This archive was generated by hypermail 2.0.0 : Mon Nov 08 2004 - 12:11:52 EST