Re: Tx - row lock contention after implementing transaction management in application server
- From: Dion Cho <ukja.dion@xxxxxxxxx>
- To: dd.yakkali@xxxxxxxxx
- Date: Wed, 27 May 2009 11:00:56 +0900
The developer's request looks not reasonable.
It's not a problem of bind value but of application design! The bind value
would continue changing if my assumption serves me right.
Anyway, getting the exact bind value of the past time is techinically
challenging topic and Oracle provides 2 easy ways for that.
1) 10046 Trace with level >=4 as Tanel described.
2) FGA(Fine Grained Auditing)
The important thing is that only proactive approach works, reactive approach
would never work.
I have a post related to this(including comments).
http://dioncho.wordpress.com/2009/05/07/tracking-the-bind-value/
================================
Dion Cho - Oracle Performance Storyteller
http://dioncho.wordpress.com (english)
http://ukja.tistory.com (korean)
================================
On Wed, May 27, 2009 at 3:41 AM, dd yakkali <dd.yakkali@xxxxxxxxx> 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
>
Other related posts:
