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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
