Andrus,
I'm sure you're very busy after being gone for a few days, but if you can
spare a couple of minutes, I'd love to hear your peliminary thoughts on the
situation described in CAY-256, even if it's something as quick as "probably
on the right track" or "probably not on the right track." I promise not to
hold you to it :)
http://objectstyle.org/jira/secure/ViewIssue.jspa?key=CAY-256
As far as I can tell, the patch is working, and I'll be putting it into our
production environment Tuesday.
I think that the situation also explains the Oct 9th bug I ran across
(reposted below).
-Mike
Begin forwarded message:
Date: Sat, 09 Oct 2004 12:14:24 -0400
From: Andrus Adamchik <andru..bjectstyle.org>
Subject: Re: Bug: Committed object considered transient by validation -- how
could it happen?
In-reply-to: <0410071656.AA587971..avilion>
To: cayenne-use..bjectstyle.org
Message-id: <492B2863-1A0E-11D9-83FD-000393B6259..bjectstyle.org>
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 : Fri Jan 07 2005 - 15:37:25 EST