Re: invalidation -> transient patch comments?

From: Mike Kienenberger (mkienen..laska.net)
Date: Fri Jan 07 2005 - 16:54:59 EST

  • Next message: Andrus Adamchik: "Re: invalidation -> transient patch comments?"

    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