Andrus Adamchik <andru..bjectstyle.org> wrote:
> 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.
Andrus,
If you have time to glance at it this weekend, that'd be great.
In case it wasn't clear (since I don't want to waste your time this week),
I'm mostly interested in your opinion of the problem itself (like, did I
correctly identify the problem?) rather than the particulars of the
solution. There's no need to spend any time on the proposed patch until
you're less busy.
Thanks,
-Mike
> > 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 - 16:52:48 EST