Hi,

well, if i do not flush, process can't work. We tried to avoid them, but
process seems to not (several circular references as i explained you a few
days ago)

I didn't get OJB test suite running (without any change of 1.0.4 binary
dist). the DB creation step crashes with an unknown CLOB type.What i'm
supposed to do to get it work ?

Would you add flush into the test, please? (as the example) and may be the
collection relation "allDetails" storing some details from shop (keep
existing 1:1 Detail relation). Key field is the same, no ?

I think the bug is due to the flush and markDelete.

Thanks for this work.

i use implicit locking, ordering, and CacheDefaultImpl.


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]
>
>

Reply via email to