Re: Tx - row lock contention after implementing transaction management in application server

On Tue, May 26, 2009 at 2:35 PM, Bobak, Mark <Mark.Bobak_at_proquest.com>wrote:

> I don’t think that’s his problem. If it were unindexed FKs, the waits
> would be on TM enqueues, not TX enqueues.
>
>
>
> -Mark
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *LS Cheng
> *Sent:* Tuesday, May 26, 2009 3:19 PM
> *To:* dd.yakkali_at_gmail.com
> *Cc:* oracle-l_at_freelists.org
> *Subject:* Re: Tx - row lock contention after implementing transaction
> management in application server
>
>
>
> Doesnt that sound like your FKs are not indexed?
>
>
>
> --
> LSC
>
> On Tue, May 26, 2009 at 8:41 PM, dd yakkali <dd.yakkali_at_gmail.com> wrote:
>
> Hello everyone,
>
>
>
> After our application folks implemented transaction management in the app,
> I am seeing a bunch of seesions waiting with "Tx - row lock contention" on
> an insert statement. we found that the parent table insert is not commited
> and hence the child record insert is hanging as both these statements are
> using different oracle sessions for some reason. This continues for
> eternity, until the app server is killled and restarted.
>
>
>
>
>
> Sun Java Enterprise Server, hibernate, oracle 10.2.0.4 RAC.
>
>
>
>
>
> Now here is the question: Our java app server folks are asking me to give
> them bind variable values of the statement that is hanging. We have a
> connection pool which is 132 connections size. Is there any way to get the
> bind variable values after the fact, i.e while it is waiting for the parent
> to commit?
>
>
>
>
>
>
>
> Thanks
>
> Deen
>
>
>

-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

--
http://www.freelists.org/webpage/oracle-l