Hi Brian,
I am trying to support "long transactions" in OTM. I didn't keep them in mind
before, but now I realized that original Raghu design contains even a special
package - swizzling - which is a way of doing long transactions.
I.e. otmconn.makePersisntent() should work similar to broker.store():
if exists then update, if doesn't exist then create. Of course, automatic
update of all changes and update via makePersisntent() are mutually
exclusive: only the object which was read inside transaction (say, via
getObjectByIdentity()) *is in transaction*. The object passed to
makePersisntent() is not included in the transaction (unless it is new),
it is just swizzled with transactional object (its fields values are copied to
the transactional object).
Regards,
Oleg
On Tuesday 02 March 2004 19:47, Brian McCallister wrote:
> I think Oleg made it safe to only fetch the master object. My
> particular example was where the Collection#remove(object) wasn't
> removing it as the object identity was different.
>
> I am pretty sure (Oleg will know better than me =) that you still need
> to obtain a reference to the parent object inside the bounds of the
> transaction.
>
> -Brian
>
> On Mar 2, 2004, at 1:28 PM, Joerg Heinicke wrote:
> > Brian McCallister <mccallister <at> forthillcompany.com> writes:
> >> Are you using an instance of the object obtained during a different
> >> transaction?
> >>
> >> for instance:
> >>
> >> public void testRemoveChildren()
> >> {
> >
> > [ ... store objects ... ]
> >
> >> Transaction tx = kit.getTransaction(otmConnection);
> >> tx.begin();
> >> parent.removeChild(child2);
> >> tx.commit();
> >
> > [ ... asserts ... ]
> >
> >> }
> >>
> >> Will fail
> >>
> >> public void testRemoveChildren()
> >> {
> >
> > [ ... store objects ... ]
> >
> >> Transaction tx = kit.getTransaction(otmConnection);
> >> tx.begin();
> >> parent = (Parent)
> >> otmConnection.getObjectByIdentity(otmConnection.getIdentity(parent));
> >> child2 = (Child)
> >> otmConnection.getObjectByIdentity(otmConnection.getIdentity(child2));
> >> parent.removeChild(child2);
> >> tx.commit();
> >
> > [ ... asserts ... ]
> >
> >> }
> >>
> >> Will pass. The objects need to be bound to the current tx.
> >>
> >> where store begins a transaction, stores, and then commits the
> >> transaction.
> >>
> >> -Brian
> >
> > Hello Brian,
> >
> > I don't know if I understand you correctly as the above seems to be
> > contradicting to Oleg's patches. The recent version of DependentTests
> > reflects
> > my wishes at best I guess [1]. I want to modify the objects outside of
> > any
> > transaction (Cocoon Forms/Woody does it for me) and make the changes
> > persistent
> > afterwards (the obects are given back to the data access layer). Of
> > course it's
> > possible that I need better identity handling to delete/update
> > correctly my
> > objects and its dependencies in my application. For that reason I used
> > the OJB
> > tests to show the effects I have and until now I could reproduce my
> > problems
> > there. If you think the current version of DependentTests is invalid
> > please tell
> > me - maybe Oleg has already to much fixed then.
> >
> > Joerg
> >
> > [1]
> > http://cvs.apache.org/viewcvs.cgi/db-ojb/src/test/org/apache/ojb/otm/
> > DependentTests.java?rev=1.4&view=markup
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
