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