Mike,
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.
Andrus
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 : Sat Oct 09 2004 - 12:14:27 EDT