Hi, On 12/8/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
Hi Bruno, Bruno CROS wrote: > Hi, > > I'm experiencing some troubles about deletePersistent usage when running > ODMG transactions. The most of the issues is an Oracle dead lock. > ORA-00060. > > I'm looking for what can be wrong, and don't find. Error occurs > on production server, never on developpement servers !! > This sounds like a concurrency issue if it isn't possible to reproduce it on development server. Did you try to write a multithreaded test to reproduce the problem?
No. I don't known how to write such a test. But i have an idea where it occurs in the persistent graph. I use locks on OJB master object (at start of transaction) when possible (even with delete). I think with this, two transactions can't run at the same time on the same part of persistent graph. It seems that it works well in all another places. Unfortunately it's hard ti do at the place where dead locks occur. Because one of transaction, is dealing with detail objects but not really master object. I'm asking me about locking master, i'm afraid that it cause more locks ! But i'm not sure.
To summarize, the transactions that produces the error is build with loops > containing several steps : > 1. unreferencing objects who have to be deleted from object that have > reference on them. 2. flush with TX Extension to produce db "updates" > posts. > 3. delete objects with getDatabase.deletePersistent(o). 4.flush to produce > "delete" posts before next iteration. > > Finally, when loop is ended, commit. > > ORA-00060 always occurs on DELETE SQL queries, as two threads would > delete/update the same record. > Did you trace/log the generated sql-statements with oracle?
In production is definitely impossible !!
I ask myself some questions : > > - Does Impl.getDatabase().deletePersistent(o) can be called several > times in > unique one transaction without trouble ? yep! As long as you don't commit the tx, Database().deletePersistent(o) should always lookup the same tx.
Good. How could i have a doubt on it... i read implementations code, was easy to see.
> - Does Impl.getDatabase().deletePersistent(o) and a flush always post a > SQL > DELETE when flush is caélled? ( mean not at commit only) yep! > > - Does the update posts of objects to be finally deleted, can lock records > when "deletes queries" are post ? e.g : unreferencing A from B and flushing > cause SQL UPDATE of B and implicitly of A (why not) then, delete A can't be > done because it is DB locked. > > What does the implicitLocking option do on DB? Nothing, the locking-api is completely independent from DB. But if the DB lock settings are more strictly then the locks used by the locking api you can get DB-locking issues. E.g. if you use ReadUncommited on OJB and RepeatedRead on DB.
My setup: ImplicitLocking=false LockAssociations=WRITE
> What are the differences between markDelete(o) and > database.deletePersistent(o) > ? at flush ? at commit ? From api of #markDelete: "Marks an object for deletion without locking the object. If the object wasn't locked before, OJB will ask for a WRITE lock at commit."
It's a good thing. I just think if it wouldn't be safer if lock is done one a master object instead of some details object. database.deletePersistent immediately locks the object and mark it for
delete. > > And according to the OJB following note about deletePersistent usage. > > "It is important to note that the Database.deletePerstient() call does not > delete the object itself, just the persistent representation of it. The > transient object still exists and can be used however desired -- it is > simply no longer persistent. " > > Is it possible OJB implicitly locks an old persistent object > (deletePersistent marked) (so transient now) and occurs a DB lock of record > (however update occurs before delete instead of the opposite)? Normally transient objects are never locked and OJB doesn't lock an object on DB (e.g. using select ... for update). regards, Armin
Thanks.
Note that > this can occur if deletePersistent DELETE posts are not done regarding the > call sequence. > > Working with 1.0.4 and some few patches, Oracle 10g. > > Thanks for answers. > > Regards. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
