Mike,
I'll take a look at it over the weekend. Indeed I am swamped with too many
things at the moment, but I should be able to do it.
Thanks
Andrus
> 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:49:10 EST