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