You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Bruno CROS <br...@gmail.com> on 2006/03/04 11:48:07 UTC
ODMG ordering with circular pairs
Hi all, hi Armin,
I believe i noted a strange behaviour behaviour of new 1.0.4 ODMG
ordering.
Consider JIRA OJB-18. Before 1.0.4 , we used the given workaround. This
means, that we put some flush() in "strategical" place to avoid all FK
constraints. It worked fine.
Now, with the OJB 1.0.4, circular or 1:1 cross references shouldn't
require flush(). I don't known how it has been made, but i assume it works.
So, i consider now that OJB can find the good order (and the back on first
object to put last reference), however we still continue to create,
reference, unreference, delete with the DB sequence.
But i'm going to try to give you an example, that worked before 1.0.4. (with
flush()) and do not any more.
-consider the circular pair of objects P1 and P2 (1:1 relation
, cross-referenced)
-consider now that we have a "M"aster object, that have a collection
of "D"etails obects, themselves referencing an instance of P1. Let's call
master object M, and details objects D.
- consider a last refrence relation between P1 and M (the master)
So, all writing process is done like this (assume "new" is instanciating and
locking at the same time):
[tx.begin]
- new M
- loop of (D)
{ - new D
- D references M
- create P1-P2 circular pair (new P1 , new P2 , P1 references P2 , P2
references P1) [flush #1]
- D references P1
}
[flush#2]
- loop on created P1
{ - lock P1 (again)
- P1 references M
}
[tx.commit]
it's schematic but I believe there is all to explain.
Our first problem was, that, after commit, P1 was not referencing M in
database. I deduced that after a flush(), new locked objects (before flush)
can't reference new ones created before flush too (a second time). Humm,
strange... we check all code : No apparent mistakes.
Then, I found this about 1.0.4 releases notes [[OJB-18] - ODMG ordering
problem with circular/bidirectional 1:1 references]. Well, OJB finds the
good order now and close the circular schema, fine. So we tried to remove
[flush #2] and process worked.
After, i said to all my team to remove flush(). Everyone was happy ! And
after [flush #1] was removed, process crashed with the FK constraints P2 to
P1 (you known, the circular pair) . It seems ODMG (without any flush) does
not find the good order to solve a "far" circular pair. I don't known why at
all.
Don't forget we have there a "double inside" circular reference (P1 & P2
inside M-D-P1 & P1-M). At first, i didn't think about resolve this
construction without 2 flushes minimum. And now, i have only one! Sorry for
headache, but i'm lost too.
I have an enourmous doubt about the other processes that still have flush
steps and work on an equivalent part of model (double circular).
Please, could you explain me the different ordering behaviours of ODMG? And
when put a flush or not?
Thanks a lot.
References : OJB 1.0.4, ObjectDefaultImpl, ODMG transactions with "same
broker" queryObject methods (to possibly retrieve instanciated objects
before commit )
Re: ODMG ordering with circular pairs
Posted by Armin Waibel <ar...@apache.org>.
Bruno CROS wrote:
> Oups, a type error at the end of my mail.
>
> "I don't think i will test this deeper, because you warned me about doing
> this (get object from other broker). "
>
> That explains the strange behaviour we had.
>
> Regards.
>
> Sorry for mistake.
>
No problem! We are interested in all problems relating to the odmg
object state detection/ordering, because we want to separate and extend
this stuff for use with PB-api too in next major release.
regards,
Armin
>
>
> On 3/7/06, Bruno CROS <br...@gmail.com> wrote:
>>
>> Hi Armin. Hi all.
>>
>> Ok. Well, i discussed about the bug with the developer who found it. After
>> we have inspected the code (really this time) we found the error.
>> There's no more bug about modifying objects after flush.
>>
>> Now, we have established some important rules to code
>> ODMG transactions (never late):
>>
>> 1. *Keep in mind database order, before writing anything*. ODMG ordering
>> is not an alternative. Circular loops have to be resolve at least by two
>> steps. (Easy, but many coders have difficulties !!)
>>
>> 2. *In case of circular references with 2 or many objects, insert some
>> flushes*, but the least possible, to keep good performance and to not have
>> to always lock objects after flushes. Sequence have to look
>> like "create-references-flush-reference/delete-commit". When references are
>> not circular, OJB ordering is really efficient, thanks the guy who wrote
>> this.
>>
>> 3. *After flush, check all objects to be modified and lock them again* (even
>> they are locked before flush) .
>>
>> 4. *Read objects that have to be modified by the transaction with the same
>> broker.* This point leaded us to write some "get" method callable under
>> and outside transaction (really great). The method get the broker of the
>> current transaction if existing, else get a default one. after read, broker
>> is closed if it have been created for the call, not if it is used by a
>> transaction.
>>
>> Last point is really important for batch, and complex schemas. For batchs,
>> it avoids the "Cannot lock for WRITE" (implicit locking helps) and for
>> complex schema, it assures that objects are well modified (and well
>> references so) till database.
>>
>> On my own, the bug described was due to a read of object with a different
>> broker than the one of transaction. I don't think i will test this deeper,
>> because you warmed me about doing this. I understand that an object can't be
>> successfull treated by transaction if read by another broker.
>>
>> We have a little work to change all read methods, but i hope everything
>> will be ok. and may be, i will try again TwoLevelCache !
>>
>> Thanks a lot.
>>
>> Glad to have your help.
>>
>> Regards.
>>
>>
>>
>>
>>
>>
>>
>> On 3/6/06, Armin Waibel <ar...@apache.org> wrote:
>>> Hi Bruno,
>>>
>>> Bruno CROS wrote:
>>>
>>>>>> Our first problem was, that, after commit, P1 was not referencing M
>>> in
>>>>>> database. I deduced that after a flush(), new locked objects (before
>>>>> flush)
>>>>>> can't reference new ones created before flush too (a second time).
>>> Humm,
>>>>>> strange... we check all code : No apparent mistakes.
>>>>
>>>> Understand reference after have been made, and not in the database.
>>>> It can be a bug for me. the reference is between 2 new instanciated
>>> and
>>>> flushed object. We have tested many times, and can't understand at
>>> all.
>>> Could you send me a test case to reproduce this issue (classes + mapping
>>> + test source)?
>>> The OJB test-suite tests handle some complex object graphs and I never
>>> notice such a problem, so it's important to reproduce your issue before
>>> we can fix it (if it's really a bug).
>>>
>>>
>>>>>> I have an enourmous doubt about the other processes that still have
>>>>> flush
>>>>>> steps and work on an equivalent part of model (double circular).
>>>>> Additional flush() calls should never cause problems. Flush only
>>> write
>>>>> the current locked objects to DB.
>>>>
>>>> Things looks to be different in my case (with 2 flushes). The object
>>> (locked
>>>> again after flush (why not)) seems to be ignored by transaction, as
>>> being
>>>> already treated !
>>> If the (repeated) locked object is not modified after lock, OJB will
>>> ignore it on commit. So are you sure that the object is modified after
>>> lock?
>>>
>>> regards,
>>> Armin
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: ODMG ordering with circular pairs
Posted by Bruno CROS <br...@gmail.com>.
Oups, a type error at the end of my mail.
"I don't think i will test this deeper, because you warned me about doing
this (get object from other broker). "
That explains the strange behaviour we had.
Regards.
Sorry for mistake.
On 3/7/06, Bruno CROS <br...@gmail.com> wrote:
>
>
> Hi Armin. Hi all.
>
> Ok. Well, i discussed about the bug with the developer who found it. After
> we have inspected the code (really this time) we found the error.
> There's no more bug about modifying objects after flush.
>
> Now, we have established some important rules to code
> ODMG transactions (never late):
>
> 1. *Keep in mind database order, before writing anything*. ODMG ordering
> is not an alternative. Circular loops have to be resolve at least by two
> steps. (Easy, but many coders have difficulties !!)
>
> 2. *In case of circular references with 2 or many objects, insert some
> flushes*, but the least possible, to keep good performance and to not have
> to always lock objects after flushes. Sequence have to look
> like "create-references-flush-reference/delete-commit". When references are
> not circular, OJB ordering is really efficient, thanks the guy who wrote
> this.
>
> 3. *After flush, check all objects to be modified and lock them again* (even
> they are locked before flush) .
>
> 4. *Read objects that have to be modified by the transaction with the same
> broker.* This point leaded us to write some "get" method callable under
> and outside transaction (really great). The method get the broker of the
> current transaction if existing, else get a default one. after read, broker
> is closed if it have been created for the call, not if it is used by a
> transaction.
>
> Last point is really important for batch, and complex schemas. For batchs,
> it avoids the "Cannot lock for WRITE" (implicit locking helps) and for
> complex schema, it assures that objects are well modified (and well
> references so) till database.
>
> On my own, the bug described was due to a read of object with a different
> broker than the one of transaction. I don't think i will test this deeper,
> because you warmed me about doing this. I understand that an object can't be
> successfull treated by transaction if read by another broker.
>
> We have a little work to change all read methods, but i hope everything
> will be ok. and may be, i will try again TwoLevelCache !
>
> Thanks a lot.
>
> Glad to have your help.
>
> Regards.
>
>
>
>
>
>
>
> On 3/6/06, Armin Waibel <ar...@apache.org> wrote:
> >
> > Hi Bruno,
> >
> > Bruno CROS wrote:
> >
> > >>> Our first problem was, that, after commit, P1 was not referencing M
> > in
> > >>> database. I deduced that after a flush(), new locked objects (before
> > >> flush)
> > >>> can't reference new ones created before flush too (a second time).
> > Humm,
> > >>> strange... we check all code : No apparent mistakes.
> > >
> > >
> > > Understand reference after have been made, and not in the database.
> > > It can be a bug for me. the reference is between 2 new instanciated
> > and
> > > flushed object. We have tested many times, and can't understand at
> > all.
> > >
> >
> > Could you send me a test case to reproduce this issue (classes + mapping
> > + test source)?
> > The OJB test-suite tests handle some complex object graphs and I never
> > notice such a problem, so it's important to reproduce your issue before
> > we can fix it (if it's really a bug).
> >
> >
> > >>> I have an enourmous doubt about the other processes that still have
> > >> flush
> > >>> steps and work on an equivalent part of model (double circular).
> > >> Additional flush() calls should never cause problems. Flush only
> > write
> > >> the current locked objects to DB.
> > >
> > >
> > > Things looks to be different in my case (with 2 flushes). The object
> > (locked
> > > again after flush (why not)) seems to be ignored by transaction, as
> > being
> > > already treated !
> >
> > If the (repeated) locked object is not modified after lock, OJB will
> > ignore it on commit. So are you sure that the object is modified after
> > lock?
> >
> > regards,
> > Armin
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
> >
> >
>
Re: ODMG ordering with circular pairs
Posted by Bruno CROS <br...@gmail.com>.
Hi Armin. Hi all.
Ok. Well, i discussed about the bug with the developer who found it. After
we have inspected the code (really this time) we found the error.
There's no more bug about modifying objects after flush.
Now, we have established some important rules to code
ODMG transactions (never late):
1. *Keep in mind database order, before writing anything*. ODMG ordering is
not an alternative. Circular loops have to be resolve at least by two steps.
(Easy, but many coders have difficulties !!)
2. *In case of circular references with 2 or many objects, insert some
flushes*, but the least possible, to keep good performance and to not have
to always lock objects after flushes. Sequence have to look
like "create-references-flush-reference/delete-commit". When references are
not circular, OJB ordering is really efficient, thanks the guy who wrote
this.
3. *After flush, check all objects to be modified and lock them again* (even
they are locked before flush) .
4. *Read objects that have to be modified by the transaction with the same
broker.* This point leaded us to write some "get" method callable under and
outside transaction (really great). The method get the broker of the current
transaction if existing, else get a default one. after read, broker is
closed if it have been created for the call, not if it is used by a
transaction.
Last point is really important for batch, and complex schemas. For batchs,
it avoids the "Cannot lock for WRITE" (implicit locking helps) and for
complex schema, it assures that objects are well modified (and well
references so) till database.
On my own, the bug described was due to a read of object with a different
broker than the one of transaction. I don't think i will test this deeper,
because you warmed me about doing this. I understand that an object can't be
successfull treated by transaction if read by another broker.
We have a little work to change all read methods, but i hope everything will
be ok. and may be, i will try again TwoLevelCache !
Thanks a lot.
Glad to have your help.
Regards.
On 3/6/06, Armin Waibel <ar...@apache.org> wrote:
>
> Hi Bruno,
>
> Bruno CROS wrote:
>
> >>> Our first problem was, that, after commit, P1 was not referencing M in
>
> >>> database. I deduced that after a flush(), new locked objects (before
> >> flush)
> >>> can't reference new ones created before flush too (a second time).
> Humm,
> >>> strange... we check all code : No apparent mistakes.
> >
> >
> > Understand reference after have been made, and not in the database.
> > It can be a bug for me. the reference is between 2 new instanciated and
> > flushed object. We have tested many times, and can't understand at all.
> >
>
> Could you send me a test case to reproduce this issue (classes + mapping
> + test source)?
> The OJB test-suite tests handle some complex object graphs and I never
> notice such a problem, so it's important to reproduce your issue before
> we can fix it (if it's really a bug).
>
>
> >>> I have an enourmous doubt about the other processes that still have
> >> flush
> >>> steps and work on an equivalent part of model (double circular).
> >> Additional flush() calls should never cause problems. Flush only write
> >> the current locked objects to DB.
> >
> >
> > Things looks to be different in my case (with 2 flushes). The object
> (locked
> > again after flush (why not)) seems to be ignored by transaction, as
> being
> > already treated !
>
> If the (repeated) locked object is not modified after lock, OJB will
> ignore it on commit. So are you sure that the object is modified after
> lock?
>
> regards,
> Armin
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: ODMG ordering with circular pairs
Posted by Armin Waibel <ar...@apache.org>.
Hi Bruno,
Bruno CROS wrote:
>>> Our first problem was, that, after commit, P1 was not referencing M in
>>> database. I deduced that after a flush(), new locked objects (before
>> flush)
>>> can't reference new ones created before flush too (a second time). Humm,
>>> strange... we check all code : No apparent mistakes.
>
>
> Understand reference after have been made, and not in the database.
> It can be a bug for me. the reference is between 2 new instanciated and
> flushed object. We have tested many times, and can't understand at all.
>
Could you send me a test case to reproduce this issue (classes + mapping
+ test source)?
The OJB test-suite tests handle some complex object graphs and I never
notice such a problem, so it's important to reproduce your issue before
we can fix it (if it's really a bug).
>>> I have an enourmous doubt about the other processes that still have
>> flush
>>> steps and work on an equivalent part of model (double circular).
>> Additional flush() calls should never cause problems. Flush only write
>> the current locked objects to DB.
>
>
> Things looks to be different in my case (with 2 flushes). The object (locked
> again after flush (why not)) seems to be ignored by transaction, as being
> already treated !
If the (repeated) locked object is not modified after lock, OJB will
ignore it on commit. So are you sure that the object is modified after lock?
regards,
Armin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: ODMG ordering with circular pairs
Posted by Bruno CROS <br...@gmail.com>.
Thanks.
Response is in red.
I'm suspecting a bug.
Regards.
On 3/5/06, Armin Waibel <ar...@apache.org> wrote:
>
> Hi Bruno,
>
> whew! Sounds really complex, I try my best...
>
> The first problem is the bidirectional reference between P1, P2. To
> establish the FK (e.g. in P1 from P2) the referenced object (P2) have to
> be persistent (else the PK of P2 will be 'null' and OJB will set FK in
> P2 'null' too).
> In CircularTest you can find examples for handling bidirectional
> references (with DB constraints) e.g.
> CircularTest#testBidirectionalWithConstraint()
>
> http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/odmg/CircularTest.java?view=markup
>
> Say we only want to insert P1,P2. In this case you can do
>
> new P1
> new P2
> flush (now both PK values exist)
> set ref P1 to P2
> set ref P2 to P1
> commit
>
> But there are other possibilities to store P1<-->P2 (see test-suite
> examples)
>
> Generally the ordering used by OJB first try to insert the 1:1
> references of an object then the object itself and then the 1:n, m:n
> references (if you don't like it, it's possible to disable OJB's
> ordering).
>
> >
> > Now, with the OJB 1.0.4, circular or 1:1 cross references shouldn't
> > require flush().
>
> This is not correct. It only mean that it is possible to handle
> bidirectional references and the user should take a look in CircularTest
>
> http://db.apache.org/ojb/docu/guides/odmg-guide.html#Circular-+and+Bidirectional+References
>
>
> > I don't known how it has been made, but i assume it works.
> > So, i consider now that OJB can find the good order (and the back on
> first
> > object to put last reference), however we still continue to create,
> > reference, unreference, delete with the DB sequence.
> >
> > But i'm going to try to give you an example, that worked before 1.0.4.
> (with
> > flush()) and do not any more.
>
> I think it worked "accidental". Before 1.0.4 when *not* using database
> identity columns (like mysql supports) the PK's are created before the
> object was stored to DB (create PK for P1 and P2, resolve references,
> set FK, insert objects).
>
>
> >
> > -consider the circular pair of objects P1 and P2 (1:1 relation
> > , cross-referenced)
> > -consider now that we have a "M"aster object, that have a collection
> > of "D"etails obects, themselves referencing an instance of P1. Let's
> call
> > master object M, and details objects D.
> > - consider a last refrence relation between P1 and M (the master)
> >
> > So, all writing process is done like this (assume "new" is instanciating
> and
> > locking at the same time):
> >
> ....
> > it's schematic but I believe there is all to explain.
> >
> > Our first problem was, that, after commit, P1 was not referencing M in
> > database. I deduced that after a flush(), new locked objects (before
> flush)
> > can't reference new ones created before flush too (a second time). Humm,
> > strange... we check all code : No apparent mistakes.
Understand reference after have been made, and not in the database.
It can be a bug for me. the reference is between 2 new instanciated and
flushed object. We have tested many times, and can't understand at all.
>
> > Then, I found this about 1.0.4 releases notes [[OJB-18] - ODMG ordering
> > problem with circular/bidirectional 1:1 references]. Well, OJB finds
> the
> > good order now and close the circular schema, fine. So we tried to
> remove
> > [flush #2] and process worked.
> >
> > After, i said to all my team to remove flush(). Everyone was happy ! And
> > after [flush #1] was removed, process crashed with the FK constraints P2
> to
> > P1 (you known, the circular pair) . It seems ODMG (without any flush)
> does
> > not find the good order to solve a "far" circular pair. I don't known
> why at
> > all.
>
> Sorry for the hassle. The explanation is given above. You should always
> ask "when will the PK exist" -> after the object is inserted. So to set
> the FK's of a P1<-->P2, P2 have to be persistent to assign the FK in P1
> and P1 have to be persistent to assign the FK in P2 -> impossible to
> find a order.
> E.g. new P1, P2, set both references and then lock P1 or P2, OJB will
> only resolve one reference, e.g. commit call--> set FK in P2 (P1 PK is
> 'null' --> FK 'null'), insert P2, set FK in P1 (PK of P1), insert P1.
>
> >
> > Don't forget we have there a "double inside" circular reference (P1 & P2
> > inside M-D-P1 & P1-M). At first, i didn't think about resolve this
> > construction without 2 flushes minimum. And now, i have only one! Sorry
> for
> > headache, but i'm lost too.
> >
>
> Isn't it great?
>
> For example, the code below should work too (with one flush)
>
> > [tx.begin]
> > - new M
> > - loop of (D)
> { new D (assume that mean add D to list/collection in M)
> D references M (think this should work ,but maybe this have be done
> after flush too)
> new P1 ,
> D references P1
> new P2 ,
> flush() (now all PK of all object should exist)
> P1 references P2 ,
> P2 references P1)
> P1 references M
> > }
> > [tx.commit]
> >
>
> > I have an enourmous doubt about the other processes that still have
> flush
> > steps and work on an equivalent part of model (double circular).
>
> Additional flush() calls should never cause problems. Flush only write
> the current locked objects to DB.
Things looks to be different in my case (with 2 flushes). The object (locked
again after flush (why not)) seems to be ignored by transaction, as being
already treated ! That is a little right (at flush).
>
> > Please, could you explain me the different ordering behaviours of ODMG?
>
> See above (when ordering is enabled, first 1:1, object itself...). If
> you disable ordering the order of objects is determined by the lock
> calls (when implicit locking is disabled too).
>
> > And
> > when put a flush or not?
>
> I can't give a rule for using flush. For best performance use it only
> when needed (each flush call perform the object detection/ordering).
>
> regards,
> Armin
>
> >
> > Thanks a lot.
> >
> > References : OJB 1.0.4, ObjectDefaultImpl, ODMG transactions with "same
> > broker" queryObject methods (to possibly retrieve instanciated objects
> > before commit )
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: ODMG ordering with circular pairs
Posted by Armin Waibel <ar...@apache.org>.
Hi Bruno,
whew! Sounds really complex, I try my best...
The first problem is the bidirectional reference between P1, P2. To
establish the FK (e.g. in P1 from P2) the referenced object (P2) have to
be persistent (else the PK of P2 will be 'null' and OJB will set FK in
P2 'null' too).
In CircularTest you can find examples for handling bidirectional
references (with DB constraints) e.g.
CircularTest#testBidirectionalWithConstraint()
http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/odmg/CircularTest.java?view=markup
Say we only want to insert P1,P2. In this case you can do
new P1
new P2
flush (now both PK values exist)
set ref P1 to P2
set ref P2 to P1
commit
But there are other possibilities to store P1<-->P2 (see test-suite
examples)
Generally the ordering used by OJB first try to insert the 1:1
references of an object then the object itself and then the 1:n, m:n
references (if you don't like it, it's possible to disable OJB's ordering).
>
> Now, with the OJB 1.0.4, circular or 1:1 cross references shouldn't
> require flush().
This is not correct. It only mean that it is possible to handle
bidirectional references and the user should take a look in CircularTest
http://db.apache.org/ojb/docu/guides/odmg-guide.html#Circular-+and+Bidirectional+References
> I don't known how it has been made, but i assume it works.
> So, i consider now that OJB can find the good order (and the back on first
> object to put last reference), however we still continue to create,
> reference, unreference, delete with the DB sequence.
>
> But i'm going to try to give you an example, that worked before 1.0.4. (with
> flush()) and do not any more.
I think it worked "accidental". Before 1.0.4 when *not* using database
identity columns (like mysql supports) the PK's are created before the
object was stored to DB (create PK for P1 and P2, resolve references,
set FK, insert objects).
>
> -consider the circular pair of objects P1 and P2 (1:1 relation
> , cross-referenced)
> -consider now that we have a "M"aster object, that have a collection
> of "D"etails obects, themselves referencing an instance of P1. Let's call
> master object M, and details objects D.
> - consider a last refrence relation between P1 and M (the master)
>
> So, all writing process is done like this (assume "new" is instanciating and
> locking at the same time):
>
....
> it's schematic but I believe there is all to explain.
>
> Our first problem was, that, after commit, P1 was not referencing M in
> database. I deduced that after a flush(), new locked objects (before flush)
> can't reference new ones created before flush too (a second time). Humm,
> strange... we check all code : No apparent mistakes.
>
> Then, I found this about 1.0.4 releases notes [[OJB-18] - ODMG ordering
> problem with circular/bidirectional 1:1 references]. Well, OJB finds the
> good order now and close the circular schema, fine. So we tried to remove
> [flush #2] and process worked.
>
> After, i said to all my team to remove flush(). Everyone was happy ! And
> after [flush #1] was removed, process crashed with the FK constraints P2 to
> P1 (you known, the circular pair) . It seems ODMG (without any flush) does
> not find the good order to solve a "far" circular pair. I don't known why at
> all.
Sorry for the hassle. The explanation is given above. You should always
ask "when will the PK exist" -> after the object is inserted. So to set
the FK's of a P1<-->P2, P2 have to be persistent to assign the FK in P1
and P1 have to be persistent to assign the FK in P2 -> impossible to
find a order.
E.g. new P1, P2, set both references and then lock P1 or P2, OJB will
only resolve one reference, e.g. commit call--> set FK in P2 (P1 PK is
'null' --> FK 'null'), insert P2, set FK in P1 (PK of P1), insert P1.
>
> Don't forget we have there a "double inside" circular reference (P1 & P2
> inside M-D-P1 & P1-M). At first, i didn't think about resolve this
> construction without 2 flushes minimum. And now, i have only one! Sorry for
> headache, but i'm lost too.
>
Isn't it great?
For example, the code below should work too (with one flush)
> [tx.begin]
> - new M
> - loop of (D)
{ new D (assume that mean add D to list/collection in M)
D references M (think this should work ,but maybe this have be done
after flush too)
new P1 ,
D references P1
new P2 ,
flush() (now all PK of all object should exist)
P1 references P2 ,
P2 references P1)
P1 references M
> }
> [tx.commit]
>
> I have an enourmous doubt about the other processes that still have flush
> steps and work on an equivalent part of model (double circular).
Additional flush() calls should never cause problems. Flush only write
the current locked objects to DB.
>
> Please, could you explain me the different ordering behaviours of ODMG?
See above (when ordering is enabled, first 1:1, object itself...). If
you disable ordering the order of objects is determined by the lock
calls (when implicit locking is disabled too).
> And
> when put a flush or not?
I can't give a rule for using flush. For best performance use it only
when needed (each flush call perform the object detection/ordering).
regards,
Armin
>
> Thanks a lot.
>
> References : OJB 1.0.4, ObjectDefaultImpl, ODMG transactions with "same
> broker" queryObject methods (to possibly retrieve instanciated objects
> before commit )
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org