I just see that there 's no "B1.set(A2)" in you proposition For me , the results is not a 1:1 cross reference.
Regards On 3/15/06, Armin Waibel <[EMAIL PROTECTED]> wrote: > > Hi Bruno, > > I setup a similar test in > CircularTest#testBidirectionalOneToOneMoveObject() > > http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/odmg/CircularTest.java?rev=386117&view=markup > > The test works like a charm. > > Compared with your post this test doesn't need flush() calls > > > 1. retrieve A1, retrieve B1 with A1.getB() > > 2. instantiation and lock of A2 > 3. lock A1, B1 (depends on the configuration settings, implicit locking) > > 4. A2.setB(B1) > 5. B1.setA(null) > > 6. delete A1 (markDelete) > > 7. commit > > regards, > Armin > > Bruno CROS wrote: > > Hi Armin, Hi all. > > > > Well, with a little confusion, we believed that our bug of complex > update > > was not one. But it remains. > > > > I'm suspecting a bug of OJB concerning the transcription of the > > "markDelete" in SQL operations. > > > > If I have time, I will try to assemble a demonstrative case of test > with > > Junit. For the moment, I give you the simplified case : > > > > Consider A1 and B1 cross referenced objetcs, each one referring the > other. > > > > The process consists with create A2, and replace A1. > > > > So, with ODMG, we wrote something like that : > > > > 1. retrieve A1, retrieve B1 with A1.getB() > > 2. instanciation and lock of A2 > > 3. A2.setB(B1) > > 4. delete A1 (markDelete) > > 5. lock B1, B1.setA(null) > > 6. flush (assume it is required) > > 7. lock B1 > > 8. B1.setA(A2) > > 9. commit > > > > After commit, we observed that in database, B1 doesn't refers A2 !! > > > > Now let's do it again (remember that B1 doesn't reference A2), let's > create > > A3. > > After commit, B1 refers well A3. > > > > We saw that the markDelete(A1) produces an update equivalent to B1.setA > (null) > > at commit without taking account of the last state of the object B1. All > > occurs as if the markDelete(A1) considers the state of B1 at the > beginning > > of the transaction (that is linked to A1 so) and decide to unreference > > A1 which have to be deleted. The evidence is that with no reference from > B1 > > to A2 at start of a new run, B1 refers well A3. Surely because there is > > nothing to unreference. > > > > I specify that the model is obviously more complex than that, but I > > preferred a simple case that a complex one. Only subtlety being a > relation > > 1:N from B to A (in more) which makes it possible to archive the objects > A > > when they have to be not deleted (another transaction does that). So > from B > > to A there is a reference-descriptor and a collection-descriptor (using > same > > DB key field) and from A to B we have 2 reference-descriptors. I do not > > believe there is a cause in that, but i give the information. There's > more > > than one flush too. Using : OJB1.0.4, DefaultCacheObjectImpl and Oracle > 9i > > and MS SQl server. > > > > We searched everywhere : repository auto-update/auto-retrieve (all at > none > > as mandatory for ODMG), bad declarations of relations (foreign key > checked), > > tx settings (ordering/not, implicit locking/not), OJB settings. No way. > > > > If someone experienced such a trouble , please tell us. > > > > Thank you for any help. > > > > Regards > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
