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 )
