Re: DB dead lock issue with deletePersistent calls

"Bruno CROS" <[email protected]>
Newsgroups gmane.comp.jakarta.ojb.user
Message-ID <[email protected]>
Hi,

Yessss, we get rid of those dead locks.

Actually, OJB does not cause anything to have Oracle dead locks!! Many
applications can have dead locks without any lines of bad (OJB) code.

Bad locks are generated when oracle can 't do simple operations as UPDATE OR
DELETE, when time to verify foreign key is simply too long ( > 1s) . This
can occur when a table reaches a big size (million of records) and if those
table haven't appropriate index on foreign key code. Mounting index on
foreign key code is necessary !! (Oracle 10)

I suggest a doclet/option to generate automatically indexes based on reverse
foreignkey  declaration code.

Anyway, a big information on documentation, about this need from big Oracle
databse.

After, DB works very faster and do not throw dead locks errors ORA-00060. I
known, this trouble only concerns only Oracle usages. But i think it have to
figure in documentation.

Regards.

Thanks for help.



On 12/8/06, Armin Waibel <[email protected]> wrote:
>
> Bruno CROS wrote:
> > 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.
>
> Only if implicit locking is enabled, else only the specified object is
> locked and not the whole graph. If not enabled you have to lock all
> objects before changing or deleting by yourself.
> You can enable implicit locking on a per tx manner using OJB's
> odmg-extensions - TxExt.
>
> http://db.apache.org/ojb/docu/guides/odmg-guide.html#The+TransactionExt+Interface
> In this case all referenced objects will implicit locked with the same
> lock mode as the master object (on very large object graphs this could
> slow down performance).
>
> regards,
> Armin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.