ORACLE 8i - DEADLOCK

Hi,
My ORACLE DATABASE 8.1.7 is stopping and giving me the folowing message:
*** 2002-05-24 11:57:42.166
*** SESSION ID:(27.3976) 2002-05-24 11:57:42.166
DEADLOCK DETECTED
Current SQL statement for this session:
DELETE FROM RECURSOSAGENDAS WHERE FK_RECURSO = :b1 AND DTAGENDA = :b2 AND HRAGENDA BETWEEN :b3 AND :b4
----- PL/SQL Call Stack -----
object line object
handle number name
1ee48eb0 21 anonymous block
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TM-00002181-00000000 13 27 S SSX 12 69 S SSX
TM-00002181-00000000 12 69 S SSX 13 27 S SSX
session 27: DID 0001-000C-00000016 session 69: DID 0001-0014-00000001
session 69: DID 0001-0014-00000001 session 27: DID 0001-000C-00000016
Rows waited on:
Session 69: no row
Session 27: no row
Someone can help me.
Thanks,
Antonio

Similar Messages

How get outside deadlock

Hi all,
i have these problem i get one "cool" app on my table which has these feature. Have deadlock problem ;). There occur situation when one sesion is select for update row with id = 10 second session take for update 20 first want take 20 then ;) and second 10 :0 and deadlock is born.
oracle find deadlock and one select is raising exception e.g.
S2 take 20
S1 take 10
S1 try take 20 and waitin
S2 try take 10 = deadlock
oracle throw error in S1
and my goal is catch this exception and try do same work in S1 again i try something like this (pseudocode)
while deadlock = true loop
deadlock := false;
savepoint s1
begin
select for update where id = 10;
select for update where id = 20;
exception
when others then
if errorcode = - 60 then deadlock :- true rollback to s1;
end;
end loop
but rollback to savepoint dont unlock my rows. can u give me advice how make this on oracle? I want loop in which i can free all my locks.
Thanks a lot martin.

Is there a reason that you can't simply avoid the deadlock by requiring that sessions lock rows in a particular order (i.e. always lock row 10 before trying to lock row 20)? Or that you can't specify NOWAIT when you try to lock the row and handle the ORA-00054 error if the row is already locked? Normally, the solution to deadlock problems is not to allow them to occur, not to try to handle them when they occur.
Justin

Deadlock detected during SELECT FOR UPDATE - an application error?

I have a general question about how Oracle prevents deadlocks from affecting
applications: do I need to build support into the application for handling
deadlocks when they occur in this particular scenario, or should Oracle handle
this for me? I'd like to know whether this is "normal" behavior for an Oracle
application, or if there is an underlying problem. Consider the following situation:
Two sessions issue individual SELECT FOR UPDATE queries. Each query locates
records in the table using a different index. These indexes point to rows in a
different order from each other, meaning that a deadlock will occur if the two
statement execute simultaneously.
For illustrative purposes, consider these rows in a hypothetical table.
ALPHABET
alpha
bravo
charlie
delta
echo
foxtrot
golf
hotel
Index A results in traversing the table in ascending alphabetical order; index
B, descending. If two SELECT FOR UPDATE statements concurrently execute on this
table--one with an ascending order execution path and one in descending order--
the two processes will deadlock at the point where they meet. If Session A
locks alpha, bravo, charlie, and delta, while Session B locks hotel, golf,
foxtrot, and echo, then neither process can proceed. A needs to lock echo, and
B needs to lock delta, but one cannot continue until the other releases its
locks.
This execution path can be encouraged using hints. Executing queries similar to these on larger tables will generate the "collision" as described above.
-- Session A
select /*+ index_asc (customer) */
from customer
where gender = 'M'
for update;
-- Session B
select /*+ index_desc (customer) */
from customer
where gender = 'M'
for update;
Oracle will recognize that both sessions are in a stand-off, and it will roll
back the work performed by one of the two sessions to break the deadlock.
My question pivots on whether or not, in this situation, the deadlock gets
reported back to the application executing the queries as an ORA-00060. If
these are the ONLY queries executed during these sessions, I would think that
Oracle would rollback the locking performed in one of the SELECT FOR UPDATE
statements. If I understand correctly,
(1) Oracle silently rolls back and replays work performed by UPDATE statements
when a deadlock situation occurs within the scope of the update statement,
and
(2) A SELECT FOR UPDATE statement causes Oracle, at the point in time the cursor
is opened, to lock all rows matching the WHERE clause.
If this is the case, then should I expect Oracle to produce an ORA-00060
deadlock detection error for two SELECT FOR UPDATE statements?
I would think that, for deadlock situations completely within Oracle's control,
this should be perceived to the application invoking the SELECT FOR UPDATE
statements as regular blocking. Since the query execution plans are the sole
reason for this deadlock situation, I think that Oracle would handle the
situation gracefully (like it does for UPDATE, as referenced in (1)).
Notice, from the trace file below, that the waits appear to be from row locking,
and not from an artificial deadlock (e.g. ITL contention).
Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production
With the Partitioning option
DEADLOCK DETECTED
Current SQL statement for this session:
SELECT XXX FROM YYY WHERE ZZZ LIKE 'AAA%' FOR UPDATE
----- PL/SQL Call Stack -----
object line object
handle number name
58a1f8f18 4 anonymous block
58a1f8f18 11 anonymous block
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-002f004b-000412cf 37 26 X 26 44 X
TX-002e0044-000638b7 26 44 X 37 26 X
session 26: DID 0001-0025-00000002 session 44: DID 0001-001A-00000002
session 44: DID 0001-001A-00000002 session 26: DID 0001-0025-00000002
Rows waited on:
Session 44: obj - rowid = 0000CE31 - AAANCFAApAAAAGBAAX
Session 26: obj - rowid = 0000CE33 - AAANCHAArAAAAOmAAM
Thanks for your insight,
- Curtis
(1) "Oracle will silently roll back your update and restart it"
http://tkyte.blogspot.com/2005/08/something-different-part-i-of-iii.html
(2) "All rows are locked when you open the cursor, not as they are fetched."
http://download-east.oracle.com/docs/cd/A87860_01/doc/appdev.817/a77069/05_ora.htm#2170
Message was edited by:
Curtis Light

Thanks for your response. In my example, I used the indexes to force a pair of query execution plans to "collide" somewhere in the table in question by having one query traverse the table via index in an ascending order, and another in descending. This is an artificial scenario for reproducible illustrative purposes, but similar collisions could legitimately occur in real world scenarios (e.g. a full table scan and an index range scan with lookup by ROWID).
So, with that said, I think it would be unreasonable for Oracle to report the collision as a ORA-00060 every time it occurs because:
(1) The UPDATE statement handles this situation automatically, and
(2) An ORA-00060 results in a 100+KB trace file being written out, only rational for truly erroneous situations.
I agree that, when the application misbehaves and locks rows out of order in separate SQL statements, then Oracle should raise an ORA-00060, as the deadlock is outside of its control. But in this case, the problem occurs with just two individual SQL statements, each within its own transaction.

Dead lock and Blocking Lock

I would like to understand what is major difference between Dead Locks and Blocking Locks in Oracle. If someone could explain or point me to good web Link I would really appreciate
Thanks.

Tony's advise is very good.
In simple terms a blocking lock is a lock being held by one session that is preventing another session from performing an DML operation on the same data until the holding session commits or rollbacks.
A deadlock is a situation where two or more sessions lock data in such a manner as each session is waiting on a resource held by another session so that none of the session can complete their unit of work. That is session A locks row 1 then session B locks row 2 followed by session A attempts to lock row 2 while session B now attemps to lock row 1. Neither session A or B will ever be able to complete thier transaction releasing the locks and allowing waiting sessions to process since each session is waiting on a resource that the other session has while holding a resource the other session needs. In other words a deadlock. Oracle detects deadlocks and kills one of the sessions freeing resources.
HTH -- Mark D Powell --

Error writing from flushModified

Friends,
Lately I am seeing this exception so often on my server. We are using BMP for
our entity beans. WL is 8.1Sp2.
I would much appreciate if any one can share his/her opinion/solution for the
issue.
Regards,
-Janiz
EJB Exception: ; nested exception is:
javax.ejb.TransactionRolledbackLocalException: Error writing from flushModified:
weblogic.ejb20.InternalException: Error writing from flushModified
     at weblogic.ejb20.manager.BeanManagedPersistenceManager.scalarFinder(BeanManagedPersistenceManager.java:77)
     at weblogic.ejb20.manager.BaseEntityManager.scalarFinder(BaseEntityManager.java:1580)
     at weblogic.ejb20.manager.BaseEntityManager.localScalarFinder(BaseEntityManager.java:1524)
     at weblogic.ejb20.internal.EntityEJBLocalHome.finder(EntityEJBLocalHome.java:463)
     at com.abc.ejb.Profile_pxe7qb_LocalHomeImpl.findByUserId(Profile_pxe7qb_LocalHomeImpl.java:122)
     at com.abc.ejb.MyEJB.getContactInfo(Unknown Source)
     at com.abc.ejb.MyEJB.getUser(Unknown Source)
     at com.abc.ejb.CustomerFacade_u478p9_EOImpl.getUser(CustomerFacade_u478p9_EOImpl.java:812)
     at com.abc.ejb.CustomerFacade_u478p9_EOImpl_WLSkel.invoke(Unknown Source)
     at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:477)
     at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:108)
     at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:420)
     at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:353)
     at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:144)
     at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:415)
     at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)

My experience with this exception is that, the ejbStore() runs sql update statement unnecessarily and that cause very high chance of deadlocking on a given db table or db row. In the Oracle db, it actually dump 2 trace files and the datetime is very close to the weblogic server log exception (if both servers got the time sync-ed).
We can simply run the ejbsession method involved with the same value in a finite tight loop(100 loops?) from 2~3 jsp pages submissions, we should be able to reproduce the problem easily.
The solution would be using lazy update inside relevant BMP ejbbeans' ejbStore(). This means using a boolean variable to keep track bean fields changed. if nothing changed, the flag will make ejbStore() running like noop, for eg,
if(!isDirty) return;
so far, this solution works well and greatly reduce the chances of running unnecessarily sql update inside ejbStore().
To Oracle, any deadlock will cause 1 of the db connection corrupted or closed silently. This seems not able to be detected by testOnReserve on jdbc connection pool.
Hope this help. Also hope more detailed reply can clarify doubts.
My weblogic is version 8.1SP2 and Oracle 9.2.

Kodo changes commit order in multithreaded scenario,resulting in DBdeadlock

We are currently using KODO version 3.4.1 as indicated by kodo-jdo-runtime-3.4.1.jar and kodo-jdo-3.4.1.jar. This is what is currently happening to our application in a scenario where multiple threads are trying to access the same set of tables. It results in a Oracle DB deadlock for one of the threads transactions. If kodo commits all the DB transactions in the same order as we had set in a particular transaction for each thread,then this deadlock wont occur, but what I noticed is that KODO changes the order in which the commit happens on the tables. Any help will be appreciated.

I have a simple example below which will illustrate actually what is happening which is resulting in a Oracle DB deadlock.
There are more that 4-5 tables that are being updated before a commit can happen.
Consider the following scenario
kodoPersistenceManager.makePersistent(table 1);
kodoPersistenceManager.makePersistent(table 2);
kodoPersistenceManager.makePersistent(table 3);
kodoPersistenceManager.makePersistent(table 4);
kodoPersistenceManager.makePersistent(table 5);
persistenceManager.close();
where persistenceManager is an instance of KodoPersistenceManager and
kodoPersistenceManager is also an instance of KodoPersistenceManager.
When multiple threads are trying to do the same operation which involves the same 6 statements as above being called, based on SQL trace thrown out by kodo I realised that kodo changes the commit order to something as shown below.
kodoPersistenceManager.makePersistent(table 2);
kodoPersistenceManager.makePersistent(table 3);
kodoPersistenceManager.makePersistent(table 1);
kodoPersistenceManager.makePersistent(table 4);
kodoPersistenceManager.makePersistent(table 5);
persistenceManager.close();
This results in a DB deadlock in the oracle database which rolls back the above transaction. There is a dependency that tables must be persisted in order table 1,table 2,table 3,table 4,table 5,table 6.
Any idea how this can be avoided? Thanks in advanvce

Deadlock issue in while inserting in oracle table.

I have written a procedure which copy data in to oracle tables.Other user can also start inserting in that table so to prevent these intervention.
i have applied locks on these two tables and assume that my procedure will wait for other users to finish and it will apply lock on the tables and other users will now wait till this procedure finishes.
My Procedure looks like:--
lock table table1 in exclusive mode;
lock table table2 in exclusive mode;
update table1 set where rownum < x;
forall .....insert in table 2.
commit;
EXCEPTION
WHEN OTHERS THEN
dbms_printline(SQLERRM)
commit;
END;
But my problem is i am still receiving oracle error as below and the above procedure fails in between:-
ORA-00060: deadlock detected while waiting for resource
Any hint ??
Can we get this error if i execute a SELECT statement on some table which is not locked by me and some other other is updating/deletig/inserting in that table ?
*Select statement is without update clause.

user620101 wrote:
I have written a procedure which copy data in to oracle tables.Other user can also start inserting in that table so to prevent these intervention.
i have applied locks on these two tables and assume that my procedure will wait for other users to finish and it will apply lock on the tables and other users will now wait till this procedure finishes.
My Procedure looks like:--
lock table table1 in exclusive mode;
lock table table2 in exclusive mode;
update table1 set where rownum < x;
forall .....insert in table 2.
commit;
EXCEPTION
WHEN OTHERS THEN
dbms_printline(SQLERRM)
commit;
END;
But my problem is i am still receiving oracle error as below and the above procedure fails in between:-
ORA-00060: deadlock detected while waiting for resource
Any hint ??But if you successfully lock TABLE1 (in session #1) and another session (session #2) is holding a lock against TABLE2 (say it's currently updating a row) then session #1 has to wait when you issue the Lock table command for table2. So session #1 is waiting, and then session #2 tries to do ANY modification to TABLE1 (which session #1 still has locked, and is still waiting to obtain the lock on TABLE2)... whamo, deadlock.
user620101 wrote:
Can we get this error if i execute a SELECT statement on some table which is not locked by me and some other other is updating/deletig/inserting in that table ?
*Select statement is without update clause.No, writes (and locks) do not block reads. So a simple select statement (unless you issued a FOR UPDATE clause) would not cause this issue.
What does your actual code look like, and what are you actually attempting to do? Why do you think you need to lock the tables, is this a one time operation, a continual operation of the system? Please explain in much more detail what you've got going on here.

ORA-00060: Deadlock detected. More info in file /oracle/dbs/admin/baandb/ud

Hi,
How to overcome with this DeadLock error.
My Users are getting this error round 3/4 times in day.
We have 175 con-current users working in OLTP environment.
SSM

Dead Lock in Oracle is usually caused by Application design flaw.
The common reason for deadlock are:
No index on foreign key column
Heavy transactions on tables with Bitmap indexes.
Asktom has some great discusstion
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4144238660486

Bug in Oracle JDBC Pooling Classes - Deadlock

We are utilizing Oracle's connection caching (drivers 10.2.0.1) and have found a deadlock situation. I reviewed the code for the (drivers 10.2.0.3) and I see the same problem could happen.
I searched and have not found this problem identified anywhere. Is this something I should post to Oracle in some way (i.e. Metalink?) or is there a better forum to get this resolved?
We are utilizing an OCI driver with the following setup in the server.xml
<ResourceParams name="cmf_toolbox">
<parameter>
<name>factory</name>
<value>oracle.jdbc.pool.OracleDataSourceFactory</value>
</parameter>
<parameter>
<name>driverClassName</name>
<value>oracle.jdbc.driver.OracleDriver</value>
</parameter>
<parameter>
<name>user</name>
<value>hidden</value>
</parameter>
<parameter>
<name>password</name>
<value>hidden</value>
</parameter>
<parameter>
<name>url</name>
<value>jdbc:oracle:oci:@PTB2</value>
</parameter>
<parameter>
<name>connectionCachingEnabled</name>
<value>true</value>
</parameter>
<parameter>
<name>connectionCacheProperties</name>
<value>(InitialLimit=5,MinLimit=15,MaxLimit=75,ConnectionWaitTimeout=30,InactivityTimeout=300,AbandonedConnectionTimeout=300,ValidateConnection=false)</value>
</parameter>
</ResourceParams>
We get a deadlock situation between two threads and the exact steps are this:
1) thread1 - The OracleImplicitConnectionClassThread class is executing the runAbandonedTimeout method which will lock the OracleImplicitConnectionCache class with a synchronized block. It will then go thru additional steps and finally try to call the LogicalConnection.close method which is already locked by thread2
2) thread2 - This thread is doing a standard .close() on the Logical Connection and when it does this it obtains a lock on the LogicalConnection class. This thread then goes through additional steps till it gets to a point in the OracleImplicitConnectionCache class where it executes the reusePooledConnection method. This method is synchronized.
Actual steps that cause deadlock:
1) thread1 locks OracleImplicitConnectionClass in runAbandonedTimeout method
2) thread2 locks LogicalConnection class in close function.
3) thread1 tries to lock the LogicalConnection and is unable to do this, waits for lock
4) thread2 tries to lock the OracleImplicitConnectionClass and waits for lock.
***DEADLOCK***
Thread Dumps from two threads listed above
thread1
Thread Name : Thread-1 State : Deadlock/Waiting on monitor Owns Monitor Lock on 0x30267fe8 Waiting for Monitor Lock on 0x509190d8 Java Stack at oracle.jdbc.driver.LogicalConnection.close(LogicalConnection.java:214) - waiting to lock 0x509190d8> (a oracle.jdbc.driver.LogicalConnection) at oracle.jdbc.pool.OracleImplicitConnectionCache.closeCheckedOutConnection(OracleImplicitConnectionCache.java:1330) at oracle.jdbc.pool.OracleImplicitConnectionCacheThread.runAbandonedTimeout(OracleImplicitConnectionCacheThread.java:261) - locked 0x30267fe8> (a oracle.jdbc.pool.OracleImplicitConnectionCache) at oracle.jdbc.pool.OracleImplicitConnectionCacheThread.run(OracleImplicitConnectionCacheThread.java:81)
thread2
Thread Name : http-7320-Processor83 State : Deadlock/Waiting on monitor Owns Monitor Lock on 0x509190d8 Waiting for Monitor Lock on 0x30267fe8 Java Stack at oracle.jdbc.pool.OracleImplicitConnectionCache.reusePooledConnection(OracleImplicitConnectionCache.java:1608) - waiting to lock 0x30267fe8> (a oracle.jdbc.pool.OracleImplicitConnectionCache) at oracle.jdbc.pool.OracleConnectionCacheEventListener.connectionClosed(OracleConnectionCacheEventListener.java:71) - locked 0x34d514f8> (a oracle.jdbc.pool.OracleConnectionCacheEventListener) at oracle.jdbc.pool.OraclePooledConnection.callImplicitCacheListener(OraclePooledConnection.java:544) at oracle.jdbc.pool.OraclePooledConnection.logicalCloseForImplicitConnectionCache(OraclePooledConnection.java:459) at oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:475) at oracle.jdbc.driver.LogicalConnection.closeInternal(LogicalConnection.java:243) at oracle.jdbc.driver.LogicalConnection.close(LogicalConnection.java:214) - locked 0x509190d8> (a oracle.jdbc.driver.LogicalConnection) at com.schoolspecialty.cmf.yantra.OrderDB.updateOrder(OrderDB.java:2022) at com.schoolspecialty.cmf.yantra.OrderFactoryImpl.saveOrder(OrderFactoryImpl.java:119) at com.schoolspecialty.cmf.yantra.OrderFactoryImpl.saveOrder(OrderFactoryImpl.java:67) at com.schoolspecialty.ecommerce.beans.ECommerceUtil.saveOrder(Unknown Source) at com.schoolspecialty.ecommerce.beans.ECommerceUtil.saveOrder(Unknown Source) at com.schoolspecialty.ecommerce.beans.UpdateCartAction.perform(Unknown Source) at com.schoolspecialty.mvc2.ActionServlet.doPost(ActionServlet.java:112) at com.schoolspecialty.ecommerce.servlets.ECServlet.doPostOrGet(Unknown Source) at com.schoolspecialty.ecommerce.servlets.ECServlet.doPost(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at com.schoolspecialty.ecommerce.servlets.filters.EcommerceURLFilter.doFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534)

We used a documented option to abandon connects in the case of an unforeseen error. The consequence of using this option was not a graceful degradation in performance but a complete lockup of the application. The scenario in which we created a moderate number of abandoned connections was a rare error scenario but a valid test.
How could this not be a bug in the Oracle driver? Is dead-lock a desireable outcome of using an option? Is dead-lock ever an acceptable consequence of using a feature as documented?
Turns out other Oracle options to recover from an unexpected error also incur a similar deadlock (TimeToLiveTimeout).
I did a code review of the decompiled drivers and it clearly shows the issue, confirming the original report of this issue. Perhaps you have evidence to the contrary or better evidence to support your statement "not a bug in Oracle"?
Perhaps you are one of the very few people who have not experience problems with Oracle drivers? I've been using Oracle since 7.3.4 and it seems that I have always been working around Oracle JDBC driver problems.
We are using Tomcat with the OracleDataSourceFactory.

Deadlock issue in Oracle 10g Partitioned Tables

Hi ALL,
I am facing an issue of Deadlock while inserting data into a partitioned table.
I get an error "ORA-00600: Deadlock detected". when i see the trace files, following lines are appearing in them:
"Single resource deadlock: blocking enqueue which blocks itself".
Here is the detail of my test case:
1. I have a list-partitioned table, with partitioning defined on some business codes.
2. I have a query that merges data into partitioned table (actually compares unique keys between temporary table and partitioned table and then issue an insert if keys not matched, no update part).
3. The temporary table contains transactional data against many business codes.
3. when calling the above query from multiple (PL/SQL) sessions, i observe that when we merge data in same partition (from different sessions) than deadlock issue occurs, otherwise it is OK.
4. Note that all sessions are executed at same time. Also note that Commit is called after each session is completed. Each session contains 2-3 more queries after the mentioned merge statement.
Is there an issue with oracle merge/insert on same partition (from different sessions)? What is the locking mechanism for this particular case (partitioned tables)?
My oracle version is Oracle 10g (10.2.0.4). Kindly advice.
Thanks,
QQ.

Could you print the deadlock tree so we can see the type and mode of the locking. (Please use the 'code' tags - see FAQ at top right of screen - to showthe output in fixed font). can you list any SQL operated by this session that gets reported in the trace file.
Does the table reference itself in a foreign key.
Is this table involved in any referential integrity constraints.
Do you have a global primary key index, or a local primary key index ?
Are there any triggers on the table - if so do they contain autonomous transactions.
At present the only though that springs to mind is that the merge command has to lock the target table to do the insert/update, but it also has to lock any child table. The mode of the child lock depends on whether it has a suitable index or not, and whether the child table IS also the parent table. If you have two merges to the same partition one partition may get its locks, and the other partition may be in a state where it can't get one of the locks because it's wait for the other. (This shouldn't be a self-deadlock, though, but the scenario might be heading in the right direction for a self-deadlock).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." (Stephen Hawking)

Problem with Oracle deadlocks

We are having severe problems with deadlocks in Oracle. We have a web-based student online course registration system that gets hit hard at the precise minute registration starts, then proceeds to generate between 100-200 trace files within 10 minutes, bringing the database to a near standstill. Every trace file contains the same SQL statement and I tried reorganizing the table referenced in the statement, allocating 100 initrans slots. This did not help at all. The application vendor is looking at their PL/SQL source, but denies that they have a problem. Does anyone have any suggestions?
Any input would be much appreciated,
Regards,
Don Morse

To solve deadlocks, the developer must ensure that in every transaction of the application, the tables are updated in same order.
That is:
Transaction 1
UPDATE T1
UPDATE T2
COMMIT
Transaction 2
UPDATE T1
UPDATE T2
COMMIT
And also, if you have multiple updates to the same table across the code of your application, they must be in the same order also.
Transaction 1
UPDATE T1 WHERE COL=1
UPDATE T1 WHERE COL=2
COMMIT
Transaction 2
UPDATE T1 WHERE COL=1
UPDATE T1 WHERE COL=2
COMMIT
If you cant be sure of the order, you can make more frecuent COMMIT, but be sure the database doesn't go inconsistent.

Oracle deadlock - how to use "synchronised" keyword in a transaction?

Hi,
I use WL6.1 SP4, Oracle 8.1.6, with some Java objects which execute a
lot
of SQL queries (mixed update, insert and select) using plain JDBC
calls,
and Weblogic connection pools. These objects are called by servlets.
I experienced recently deadlocks when two users call the object at the
same
time (See error below).
I execute the queries using "synchronized" keyword in the following
way:
synchronized (this)
conConnection.setAutoCommit(false);
executeTransaction(myStatement);
conConnection.commit();
executeTransaction is overriden in sub-classes and is the method which
executes
all the queries.
It calls methods in other objects. These methods are not declared as
synchronized.
1) Should they?
2) Should I use the keyword "synchronized" in another way?
3) This part of code is also called when I do only "select"
statements. I guess
it should only be synchronized when we do "update" and "insert" which
could lead
to a deadlock?
4) Do you have any idea why this deadlock occurs as I use the
"synchronized"
keyword, and one thread should wait until the other one has finished?
Thanks for any idea,
Stéphanie
----------------- error:
<ExecuteThread: '4' for queue: 'default'> <> <> <000000> <SQL request
sent to database: UPDATE PARTICIPANT par SET par.PARTICIPANTLASTRANK =
4 WHERE par.IDPARTICIPANT = 8983566>
<ExecuteThread: '11' for queue: 'default'> <> <> <000000> <SQL request
sent to database: UPDATE PARTICIPANT par SET par.PARTICIPANTLASTRANK =
6 WHERE par.IDPARTICIPANT = 8983570>
ORA-00060: deadlock detected while waiting for resource
     at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
     at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
     at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:573)
     at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1891)
     at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:1093)
     at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2047)
     at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1940)
     at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2709)
     at oracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:796)
     at weblogic.jdbc.pool.Statement.executeUpdate(Statement.java:872)
     at weblogic.jdbc.rmi.internal.StatementImpl.executeUpdate(StatementImpl.java:89)
     at weblogic.jdbc.rmi.SerialStatement.executeUpdate(SerialStatement.java:100)
     at bfinance.framework.EDBBLBean.executeSQL(EDBBLBean.java:299)

Hi Stepanie,
I'd try to group update statement together. Usually it helps.
Regards,
Slava Imeshev
"Stephanie" <[email protected]> wrote in message
news:[email protected]...
Thanks for your answer.
In the case you describe, is there a way to ensure that tx-2 waits for
tx-1
to be finished before beginning?
My transaction which causes the problem is the following (simplified):
UPDATE tableA SET islast=0 WHERE externalid=myid;
for (int i=0; i< aVector.size(); i++) {
INSERT INTO tableA (id, islast, ranking, externalid) (SELECT
SEQ_tableA.nextval, 1, 0, myid);
UPDATE tableA SET ranking = /*calculated ranking */
WHERE externalid=myid AND islast=1;
UPDATE tableB ....
commit;
tx-1 and tx-2 execute this transaction at the same time. tx-1 begins
The deadlock appears when tx-2 executes the second UPDATE tableA
query.
I don't see how I can avoid to execute these two update queries, so if
I can find another way to prevent deadlock, it would be great!
Stéphanie
Joseph Weinstein <[email protected]_this> wrote in message
news:<[email protected]_this>...
Stephanie wrote:
Hi,
I use WL6.1 SP4, Oracle 8.1.6, with some Java objects which execute a
lot
of SQL queries (mixed update, insert and select) using plain JDBC
calls,
and Weblogic connection pools. These objects are called by servlets.
I experienced recently deadlocks when two users call the object at the
same
time (See error below).Hi. The error you are getting isn't necessarily from a lack ofsynchronization
of your java objects. It has to do with the order in which you accessDBMS
data. You are getting ordinary DBMS deadlocks, which are caused when
two DBMS connections each have a lock the other wants, in order toproceed.
The DBMS will quickly discover this and will kill one transaction inorder to
let the other one proceed:
time 0: tx-1 and tx-2 have started.....
time 1: tx-1: update tableA set val = 1 where key = 'A'
time 2: tx-2: update tableB set val = 2 where key = 'B'
time 3: tx-1: update tableB set val = 1 where key = 'B' (waitsbecause tx-2 has the row
locked)
time 4: tx-2: update tableA set val = 2 where key = 'A' (waitsbecause tx-1 has the row
locked)
This is a deadlock. The solution is to organize your application code sothat every
transaction accesses the data in the same order, eg: update tableAfirst, then update tableB.
This will prevent deadlocks.
Joe Weinstein at BEA
I execute the queries using "synchronized" keyword in the following
way:
synchronized (this)
conConnection.setAutoCommit(false);
executeTransaction(myStatement);
conConnection.commit();
executeTransaction is overriden in sub-classes and is the method which
executes
all the queries.
It calls methods in other objects. These methods are not declared as
synchronized.
1) Should they?
2) Should I use the keyword "synchronized" in another way?
3) This part of code is also called when I do only "select"
statements. I guess
it should only be synchronized when we do "update" and "insert" which
could lead
to a deadlock?
4) Do you have any idea why this deadlock occurs as I use the
"synchronized"
keyword, and one thread should wait until the other one has finished?
Thanks for any idea,
Stéphanie
----------------- error:
<ExecuteThread: '4' for queue: 'default'> <> <> <000000> <SQL request
sent to database: UPDATE PARTICIPANT par SET par.PARTICIPANTLASTRANK =
4 WHERE par.IDPARTICIPANT = 8983566>
<ExecuteThread: '11' for queue: 'default'> <> <> <000000> <SQL request
sent to database: UPDATE PARTICIPANT par SET par.PARTICIPANTLASTRANK =
6 WHERE par.IDPARTICIPANT = 8983570>
ORA-00060: deadlock detected while waiting for resource
at
oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:573)
atoracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1891)
atoracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:1093)
atoracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2047
atoracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1940)
atoracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java
:2709)
atoracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:796)
atweblogic.jdbc.pool.Statement.executeUpdate(Statement.java:872)
atweblogic.jdbc.rmi.internal.StatementImpl.executeUpdate(StatementImpl.java:89
atweblogic.jdbc.rmi.SerialStatement.executeUpdate(SerialStatement.java:100)
at bfinance.framework.EDBBLBean.executeSQL(EDBBLBean.java:299)

Deadlock in Oracle.sql.ARRAY type

Hi,
We've come across the deadlock situation below when running multiple J2EE MDB instances that are trying to write to the DB:
[deadlocked thread] [ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)':
Thread '[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)'' is waiting to acquire lock 'oracle.jdbc.driver.T4CConnection@90106ee' that is held by thread '[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)''
Stack trace:
oracle.sql.ARRAY.toBytes(ARRAY.java:673)
oracle.jdbc.driver.OraclePreparedStatement.setArrayCritical(OraclePreparedStatement.java:5985)
oracle.jdbc.driver.OraclePreparedStatement.setARRAYInternal(OraclePreparedStatement.java:5944)
oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:8782)
oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:8278)
oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:8868)
oracle.jdbc.driver.OraclePreparedStatementWrapper.setObject(OraclePreparedStatementWrapper.java:240)
weblogic.jdbc.wrapper.PreparedStatement.setObject(PreparedStatement.java:287)
org.springframework.jdbc.core.StatementCreatorUtils.setValue(StatementCreatorUtils.java:356)
org.springframework.jdbc.core.StatementCreatorUtils.setParameterValueInternal(StatementCreatorUtils.java:216)
org.springframework.jdbc.core.StatementCreatorUtils.setParameterValue(StatementCreatorUtils.java:127)
org.springframework.jdbc.core.PreparedStatementCreatorFactory$PreparedStatementCreatorImpl.setValues(PreparedStatementCreatorFactory.java:298)
org.springframework.jdbc.object.BatchSqlUpdate$1.setValues(BatchSqlUpdate.java:192)
org.springframework.jdbc.core.JdbcTemplate$4.doInPreparedStatement(JdbcTemplate.java:892)
org.springframework.jdbc.core.JdbcTemplate$4.doInPreparedStatement(JdbcTemplate.java:1)
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:586)
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:614)
org.springframework.jdbc.core.JdbcTemplate.batchUpdate(JdbcTemplate.java:883)
org.springframework.jdbc.object.BatchSqlUpdate.flush(BatchSqlUpdate.java:184)
com.csfb.fao.rds.rfi.common.dao.storedprocs.SaveEarlyExceptionBatchStoredProc.execute(SaveEarlyExceptionBatchStoredProc.java:93)
com.csfb.fao.rds.rfi.common.dao.EarlyExceptionDAOImpl.saveEarlyExceptionBatch(EarlyExceptionDAOImpl.java:34)
com.csfb.fao.rds.rfi.application.rulesengine.RulesEngine.saveEarlyExceptions(RulesEngine.java:302)
com.csfb.fao.rds.rfi.application.rulesengine.RulesEngine.executeRules(RulesEngine.java:209)
com.csfb.fao.rds.rfi.application.rulesengine.RulesEngine.onMessage(RulesEngine.java:97)
com.csfb.fao.rds.feeds.process.BaseWorkerMDB.onMessage(BaseWorkerMDB.java:518)
weblogic.ejb.container.internal.MDListener.execute(MDListener.java:466)
weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:371)
weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:327)
weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4547)
weblogic.jms.client.JMSSession.execute(JMSSession.java:4233)
weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3709)
weblogic.jms.client.JMSSession.access$000(JMSSession.java:114)
weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5058)
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
[deadlocked thread] [ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)':
Thread '[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'' is waiting to acquire lock 'oracle.jdbc.driver.T4CConnection@b48b568' that is held by thread '[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)''
Stack trace:
oracle.sql.ARRAY.toBytes(ARRAY.java:673)
oracle.jdbc.driver.OraclePreparedStatement.setArrayCritical(OraclePreparedStatement.java:5985)
oracle.jdbc.driver.OraclePreparedStatement.setARRAYInternal(OraclePreparedStatement.java:5944)
oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:8782)
oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:8278)
oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:8868)
oracle.jdbc.driver.OraclePreparedStatementWrapper.setObject(OraclePreparedStatementWrapper.java:240)
weblogic.jdbc.wrapper.PreparedStatement.setObject(PreparedStatement.java:287)
org.springframework.jdbc.core.StatementCreatorUtils.setValue(StatementCreatorUtils.java:356)
org.springframework.jdbc.core.StatementCreatorUtils.setParameterValueInternal(StatementCreatorUtils.java:216)
org.springframework.jdbc.core.StatementCreatorUtils.setParameterValue(StatementCreatorUtils.java:127)
org.springframework.jdbc.core.PreparedStatementCreatorFactory$PreparedStatementCreatorImpl.setValues(PreparedStatementCreatorFactory.java:298)
org.springframework.jdbc.object.BatchSqlUpdate$1.setValues(BatchSqlUpdate.java:192)
org.springframework.jdbc.core.JdbcTemplate$4.doInPreparedStatement(JdbcTemplate.java:892)
org.springframework.jdbc.core.JdbcTemplate$4.doInPreparedStatement(JdbcTemplate.java:1)
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:586)
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:614)
org.springframework.jdbc.core.JdbcTemplate.batchUpdate(JdbcTemplate.java:883)
org.springframework.jdbc.object.BatchSqlUpdate.flush(BatchSqlUpdate.java:184)
com.csfb.fao.rds.rfi.common.dao.storedprocs.SaveEarlyExceptionBatchStoredProc.execute(SaveEarlyExceptionBatchStoredProc.java:93)
com.csfb.fao.rds.rfi.common.dao.EarlyExceptionDAOImpl.saveEarlyExceptionBatch(EarlyExceptionDAOImpl.java:34)
com.csfb.fao.rds.rfi.application.rulesengine.RulesEngine.saveEarlyExceptions(RulesEngine.java:302)
com.csfb.fao.rds.rfi.application.rulesengine.RulesEngine.executeRules(RulesEngine.java:209)
com.csfb.fao.rds.rfi.application.rulesengine.RulesEngine.onMessage(RulesEngine.java:97)
com.csfb.fao.rds.feeds.process.BaseWorkerMDB.onMessage(BaseWorkerMDB.java:518)
weblogic.ejb.container.internal.MDListener.execute(MDListener.java:466)
weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:371)
weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:327)
weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4547)
weblogic.jms.client.JMSSession.execute(JMSSession.java:4233)
weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3709)
weblogic.jms.client.JMSSession.access$000(JMSSession.java:114)
weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5058)
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Looking at the ARRAY.toBytes() method:
public byte[] toBytes()
throws SQLException
synchronized (getInternalConnection())
return this.descriptor.toBytes(this, this.enableBuffering);
..., it synchronizes on the following method (getInternalConnection() -> getPhysicalConnection()):
oracle.jdbc.internal.OracleConnection getPhysicalConnection()
if (this.physicalConnection == null)
try
this.physicalConnection = ((oracle.jdbc.internal.OracleConnection)new OracleDriver().defaultConnection());
catch (SQLException localSQLException)
return this.physicalConnection;
defaultConnection() does the following:
public Connection defaultConnection()
throws SQLException
if ((defaultConn == null) || (defaultConn.isClosed()))
synchronized (OracleDriver.class)
if ((defaultConn == null) || (defaultConn.isClosed()))
defaultConn = connect("jdbc:oracle:kprb:", new Properties());
return defaultConn;
So there's synchronizations on the connection instance and OracleDriver.class object... I can't see how this can deadlock. To get to the point of needing the lock on OracleDriver.class, the thread would already have the lock on the connection instance.... clearly I'm missing something.
Thanks
Edited by: 928154 on 17-Apr-2012 03:42

Welcome to the forum. If you want help, at least try to think where to post a question and look for a forum that matches the topic. Lets examine what you have:
- its Weblogic, so if you would ask a non-programming related question anywhere it would be in the Weblogic forum
- HOWEVER, if you check the top of the stacktrace, you'll see that the problem stems from the JDBC driver, so a JDBC related forum would be a closer match
For future reference, Weblogic specific questions should go here: https://forums.oracle.com/forums/category.jspa?categoryID=193
and JDBC/OJDBC driver related questions should go here: Java Database Connectivity (JDBC)
Final tip: use \ tags to post code so it is readable.

Deadlock in Oracle XA classes

Hi,
I am using Oracle XA with connection pooling for distributed transactions. According to the JTA spec, an XAResource instance can be reused for 2PC handling while it has a transaction context associated to it. Yet when I do this, I get a deadlock in the Java VM, as shown below. The blocking seems to happen inside the Oracle classes entirely, therefore I doubt that this is my fault...
The problem happens because one thread is closing the connection, when another is doing the prepare on its resource...
Did anybody else have this? Am I doing something wrong or is this internal?
Regards,
Guy
Type number corresponding to selected action: 1
FOUND A JAVA LEVEL DEADLOCK:
t@206 waiting to lock object@0xe92a0e80:"oracle/jdbc/driver/OracleConnection"
which is locked by t@200
t@200 waiting to lock object@0xe93c0e90:"oracle/jdbc/driver/OracleCallableStatement"
which is locked by t@206
JAVA STACK INFORMATION FOR THREADS LISTED ABOVE:
Java Stack for t@206 (EE = 0x6336d8) "Thread-78" :
==========
[1] oracle.jdbc.driver.OracleConnection.needLine(OracleConnection.java:1150)
[2] oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1204)
[3] oracle.jdbc.driver.OracleStatement.doExecuteWithBatch(OracleStatement.java:1339)
[4] oracle.jdbc.driver.OracleStatement.doExecute(OracleStatement.java:1750)
[5] oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1770)
[6] oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:305)
[7] oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:356)
[8] oracle.jdbc.xa.client.OracleXAResource.prepare(OracleXAResource.java:288)
[9] ch.ethz.inf.datasource.XARecoverableResource.prepare(XARecoverableResource.java:243)
[10] ch.ethz.inf.cheetah.CompositeTransactionImp.TMprepare(CompositeTransactionImp.java:755)
[11] ch.ethz.inf.cheetah.PrepareMapping.doIt(PrepareMapping.java:25)
[12] ch.ethz.inf.cheetah.RootSetImp.traverse(RootSetImp.java)
[13] ch.ethz.inf.cheetah.RootSetImp.TMprepare(RootSetImp.java)
[14] ch.ethz.inf.cheetah.RootSetImp.TMprepare(RootSetImp.java)
[15] ch.ethz.inf.cheetah.CompositeTxMgrImp.commit(CompositeTxMgrImp.java:923)
[16] ch.ethz.inf.cheetah.CompositeTxMgrImp.end(CompositeTxMgrImp.java:621)
[17] ch.ethz.inf.propagation.TxServerStub.endTransactionContext(TxServerStub.java:136)
[18] ch.ethz.inf.propagation.XATestServiceStub.doIt(XATestServiceStub.java:20)
[19] ch.ethz.inf.propagation.TestServiceClientStub.doIt(TestServiceClientStub.java:28)
[20] ch.ethz.inf.propagation.TestPropagation.run(TestPropagation.java:344)
[21] java.lang.Thread.run(Thread.java:478)
Java Stack for t@200 (EE = 0x2e3550) "Thread-76" :
==========
[1] oracle.jdbc.driver.OraclePreparedStatement.close(OraclePreparedStatement.java:236)
[2] oracle.jdbc.driver.OracleConnection.close_statements(OracleConnection.java:1137)
[3] oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:527)
[4] oracle.jdbc.pool.OraclePooledConnection.close(OraclePooledConnection.java:143)
[5] ch.ethz.inf.datasource.XAPooledConnection.close(XAPooledConnection.java:85)
[6] ch.ethz.inf.datasource.ConnectionPool.connectionClosed(ConnectionPool.java:114)
[7] ch.ethz.inf.datasource.XAConnectionPool.connectionClosed(XAConnectionPool.java:111)
[8] ch.ethz.inf.datasource.XAPooledConnection.connectionClosed(XAPooledConnection.java:113)
[9] oracle.jdbc.pool.OraclePooledConnection.callListener(OraclePooledConnection.java:223)
[10] oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:214)
[11] oracle.jdbc.driver.OracleConnection.logicalClose(OracleConnection.java:1586)
[12] oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:527)
[13] ch.ethz.inf.propagation.XATestService.doIt(XATestService.java:32)
[14] ch.ethz.inf.propagation.XATestServiceStub.doIt(XATestServiceStub.java:20)
[15] ch.ethz.inf.propagation.TestServiceClientStub.doIt(TestServiceClientStub.java:28)
[16] ch.ethz.inf.propagation.TestPropagation.run(TestPropagation.java:344)
[17] java.lang.Thread.run(Thread.java:478)
Found 1 deadlock
null

Hi,
I am using Oracle XA with connection pooling for distributed transactions. According to the JTA spec, an XAResource instance can be reused for 2PC handling while it has a transaction context associated to it. Yet when I do this, I get a deadlock in the Java VM, as shown below. The blocking seems to happen inside the Oracle classes entirely, therefore I doubt that this is my fault...
The problem happens because one thread is closing the connection, when another is doing the prepare on its resource...
Did anybody else have this? Am I doing something wrong or is this internal?
Regards,
Guy
Type number corresponding to selected action: 1
FOUND A JAVA LEVEL DEADLOCK:
t@206 waiting to lock object@0xe92a0e80:"oracle/jdbc/driver/OracleConnection"
which is locked by t@200
t@200 waiting to lock object@0xe93c0e90:"oracle/jdbc/driver/OracleCallableStatement"
which is locked by t@206
JAVA STACK INFORMATION FOR THREADS LISTED ABOVE:
Java Stack for t@206 (EE = 0x6336d8) "Thread-78" :
==========
[1] oracle.jdbc.driver.OracleConnection.needLine(OracleConnection.java:1150)
[2] oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1204)
[3] oracle.jdbc.driver.OracleStatement.doExecuteWithBatch(OracleStatement.java:1339)
[4] oracle.jdbc.driver.OracleStatement.doExecute(OracleStatement.java:1750)
[5] oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1770)
[6] oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:305)
[7] oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:356)
[8] oracle.jdbc.xa.client.OracleXAResource.prepare(OracleXAResource.java:288)
[9] ch.ethz.inf.datasource.XARecoverableResource.prepare(XARecoverableResource.java:243)
[10] ch.ethz.inf.cheetah.CompositeTransactionImp.TMprepare(CompositeTransactionImp.java:755)
[11] ch.ethz.inf.cheetah.PrepareMapping.doIt(PrepareMapping.java:25)
[12] ch.ethz.inf.cheetah.RootSetImp.traverse(RootSetImp.java)
[13] ch.ethz.inf.cheetah.RootSetImp.TMprepare(RootSetImp.java)
[14] ch.ethz.inf.cheetah.RootSetImp.TMprepare(RootSetImp.java)
[15] ch.ethz.inf.cheetah.CompositeTxMgrImp.commit(CompositeTxMgrImp.java:923)
[16] ch.ethz.inf.cheetah.CompositeTxMgrImp.end(CompositeTxMgrImp.java:621)
[17] ch.ethz.inf.propagation.TxServerStub.endTransactionContext(TxServerStub.java:136)
[18] ch.ethz.inf.propagation.XATestServiceStub.doIt(XATestServiceStub.java:20)
[19] ch.ethz.inf.propagation.TestServiceClientStub.doIt(TestServiceClientStub.java:28)
[20] ch.ethz.inf.propagation.TestPropagation.run(TestPropagation.java:344)
[21] java.lang.Thread.run(Thread.java:478)
Java Stack for t@200 (EE = 0x2e3550) "Thread-76" :
==========
[1] oracle.jdbc.driver.OraclePreparedStatement.close(OraclePreparedStatement.java:236)
[2] oracle.jdbc.driver.OracleConnection.close_statements(OracleConnection.java:1137)
[3] oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:527)
[4] oracle.jdbc.pool.OraclePooledConnection.close(OraclePooledConnection.java:143)
[5] ch.ethz.inf.datasource.XAPooledConnection.close(XAPooledConnection.java:85)
[6] ch.ethz.inf.datasource.ConnectionPool.connectionClosed(ConnectionPool.java:114)
[7] ch.ethz.inf.datasource.XAConnectionPool.connectionClosed(XAConnectionPool.java:111)
[8] ch.ethz.inf.datasource.XAPooledConnection.connectionClosed(XAPooledConnection.java:113)
[9] oracle.jdbc.pool.OraclePooledConnection.callListener(OraclePooledConnection.java:223)
[10] oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:214)
[11] oracle.jdbc.driver.OracleConnection.logicalClose(OracleConnection.java:1586)
[12] oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:527)
[13] ch.ethz.inf.propagation.XATestService.doIt(XATestService.java:32)
[14] ch.ethz.inf.propagation.XATestServiceStub.doIt(XATestServiceStub.java:20)
[15] ch.ethz.inf.propagation.TestServiceClientStub.doIt(TestServiceClientStub.java:28)
[16] ch.ethz.inf.propagation.TestPropagation.run(TestPropagation.java:344)
[17] java.lang.Thread.run(Thread.java:478)
Found 1 deadlock
null

Deadlock in oracle JDBC driver

I've been doing testing on a 12 CPU SunFire 6800 and am seeing the
Oracle JDBC driver that ships with weblogic deadlock in Java. Has
anyone else come across this?
Also, does anyone know how to find the version of the oracle driver or simply know which version WebLogic 6.1 ships with?
thank you
FOUND A JAVA LEVEL DEADLOCK:
"ExecuteThread: '180' for queue: 'default'":
waiting to lock monitor 0xcbb28 (object 0xdee1d070, a oracle.jdbc.driver.OraclePreparedStatement),
which is locked by "ExecuteThread: '73' for queue: 'default'"
"ExecuteThread: '73' for queue: 'default'":
waiting to lock monitor 0xcbc78 (object 0xdec416b8, a oracle.jdbc.driver.OracleConnection),
which is locked by "ExecuteThread: '180' for queue: 'default'"
JAVA STACK INFORMATION FOR THREADS LISTED ABOVE:
Java Stack for "ExecuteThread: '180' for queue: 'default'":
==========
     at oracle.jdbc.driver.OraclePreparedStatement.sendBatch(OraclePreparedStatement.java:431)
     at oracle.jdbc.driver.OracleConnection.commit(OracleConnection.java:838)
     at weblogic.jdbc.jts.Connection.internalCommit(Connection.java:697)
     at weblogic.jdbc.jts.Connection.commit(Connection.java:415)
     at weblogic.transaction.internal.ServerResourceInfo.commit(ServerResourceInfo.java:1180)
     at weblogic.transaction.internal.ServerResourceInfo.commit(ServerResourceInfo.java:419)
     at weblogic.transaction.internal.ServerSCInfo.startCommit(ServerSCInfo.java:233)
     at weblogic.transaction.internal.ServerTransactionImpl.localCommit(ServerTransactionImpl.java:1397)
     at weblogic.transaction.internal.ServerTransactionImpl.globalRetryCommit(ServerTransactionImpl.java:1940)
     at weblogic.transaction.internal.ServerTransactionImpl.globalCommit(ServerTransactionImpl.java:1886)
     at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:221)
     at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:190)
     at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:231)
     at com.fourthpass.wpserver.request.RequestProcessorBean_p612k3_EOImpl.processRequest(RequestProcessorBean_p612k3_EOImpl.java:46)
     at com.fourthpass.wpserver.handlers.deviceAdapter.AbstractDeviceHandler.processRequest(AbstractDeviceHandler.java:97)
     at com.fourthpass.wpserver.irm.http.RequestHandler.process(RequestHandler.java:190)
     at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doRequest(HttpRequestHandlerServlet.java:128)
     at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doGet(HttpRequestHandlerServlet.java:78)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
     at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2495)
     at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2204)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Java Stack for "ExecuteThread: '73' for queue: 'default'":
==========
     at oracle.jdbc.driver.OracleConnection.getDefaultRowPrefetch(OracleConnection.java:1263)
     at oracle.jdbc.driver.OracleStatement.setFetchSize(OracleStatement.java:4878)
     at weblogic.jdbc.common.internal.ConnectionEnv.cleanUpStatementForReUse(ConnectionEnv.java:747)
     at weblogic.jdbc.common.internal.ConnectionEnv.dropStatement(ConnectionEnv.java:719)
     at weblogic.jdbc.jts.Statement.close(Statement.java:231)
     at weblogic.jdbc.rmi.internal.StatementImpl.close(StatementImpl.java:97)
     at weblogic.jdbc.rmi.SerialStatement.close(SerialStatement.java:123)
     at weblogic.jdbc.rmi.SerialStatement.close(SerialStatement.java:113)
     at weblogic.ejb20.cmp11.rdbms.PersistenceManagerImpl.releaseStatement(PersistenceManagerImpl.java:596)
     at weblogic.ejb20.cmp11.rdbms.PersistenceManagerImpl.releaseResources(PersistenceManagerImpl.java:562)
     at weblogic.ejb20.cmp11.rdbms.PersistenceManagerImpl.releaseResources(PersistenceManagerImpl.java:531)
     at com.fourthpass.wpserver.billingentities.PendingBillingInfo_6hg1f2__WebLogic_CMP_RDBMS.ejbRemove(PendingBillingInfo_6hg1f2__WebLogic_CMP_RDBMS.java:1135)
     at weblogic.ejb20.manager.DBManager.remove(DBManager.java:627)
     at weblogic.ejb20.internal.EntityEJBObject.remove(EntityEJBObject.java:117)
     at com.fourthpass.wpserver.billingentities.PendingBillingInfoBeanCMP_6hg1f2_EOImpl.remove(PendingBillingInfoBeanCMP_6hg1f2_EOImpl.java:559)
     at com.fourthpass.wpserver.billing.BillingBean.movePendingToActiveBilling(BillingBean.java:1442)
     at com.fourthpass.wpserver.billing.BillingBean.reportSuccessfulInstallation(BillingBean.java:1349)
     at com.fourthpass.wpserver.billing.BillingBean.reportApplicationInstallStatusCode(BillingBean.java:968)
     at com.fourthpass.wpserver.billing.BillingBean.reportApplicationInstallStatusCode(BillingBean.java:937)
     at com.fourthpass.wpserver.billing.BillingBean_t3moiz_EOImpl.reportApplicationInstallStatusCode(BillingBean_t3moiz_EOImpl.java:1265)
     at com.fourthpass.wpserver.handlers.request.mascommands.InstallNotifyCommand.handleOtaEvent(InstallNotifyCommand.java:187)
     at com.fourthpass.wpserver.handlers.request.mascommands.InstallNotifyCommand.process(InstallNotifyCommand.java:94)
     at com.fourthpass.wpserver.request.handlers.MASRequestHandler.process(MASRequestHandler.java:90)
     at com.fourthpass.wpserver.request.RequestProcessorBean.processRequest(RequestProcessorBean.java:113)
     at com.fourthpass.wpserver.request.RequestProcessorBean_p612k3_EOImpl.processRequest(RequestProcessorBean_p612k3_EOImpl.java:37)
     at com.fourthpass.wpserver.handlers.deviceAdapter.AbstractDeviceHandler.processRequest(AbstractDeviceHandler.java:97)
     at com.fourthpass.wpserver.irm.http.RequestHandler.process(RequestHandler.java:190)
     at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doRequest(HttpRequestHandlerServlet.java:128)
     at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doPost(HttpRequestHandlerServlet.java:89)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
     at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2495)
     at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2204)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Found 1 deadlock.

Chad Urso McDaniel wrote:
I've been doing testing on a 12 CPU SunFire 6800 and am seeing the
Oracle JDBC driver that ships with weblogic deadlock in Java. Has
anyone else come across this?
Also, does anyone know how to find the version of the oracle driver or simply know which version WebLogic 6.1 ships with?Oracle does have later driver versions, so do download it and make sure it's ahead of all weblogic
stuff in the server's classpath (as it is created by the start script).
Joe
>
>
thank you
FOUND A JAVA LEVEL DEADLOCK:
"ExecuteThread: '180' for queue: 'default'":
waiting to lock monitor 0xcbb28 (object 0xdee1d070, a oracle.jdbc.driver.OraclePreparedStatement),
which is locked by "ExecuteThread: '73' for queue: 'default'"
"ExecuteThread: '73' for queue: 'default'":
waiting to lock monitor 0xcbc78 (object 0xdec416b8, a oracle.jdbc.driver.OracleConnection),
which is locked by "ExecuteThread: '180' for queue: 'default'"
JAVA STACK INFORMATION FOR THREADS LISTED ABOVE:
Java Stack for "ExecuteThread: '180' for queue: 'default'":
==========
at oracle.jdbc.driver.OraclePreparedStatement.sendBatch(OraclePreparedStatement.java:431)
at oracle.jdbc.driver.OracleConnection.commit(OracleConnection.java:838)
at weblogic.jdbc.jts.Connection.internalCommit(Connection.java:697)
at weblogic.jdbc.jts.Connection.commit(Connection.java:415)
at weblogic.transaction.internal.ServerResourceInfo.commit(ServerResourceInfo.java:1180)
at weblogic.transaction.internal.ServerResourceInfo.commit(ServerResourceInfo.java:419)
at weblogic.transaction.internal.ServerSCInfo.startCommit(ServerSCInfo.java:233)
at weblogic.transaction.internal.ServerTransactionImpl.localCommit(ServerTransactionImpl.java:1397)
at weblogic.transaction.internal.ServerTransactionImpl.globalRetryCommit(ServerTransactionImpl.java:1940)
at weblogic.transaction.internal.ServerTransactionImpl.globalCommit(ServerTransactionImpl.java:1886)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:221)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:190)
at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:231)
at com.fourthpass.wpserver.request.RequestProcessorBean_p612k3_EOImpl.processRequest(RequestProcessorBean_p612k3_EOImpl.java:46)
at com.fourthpass.wpserver.handlers.deviceAdapter.AbstractDeviceHandler.processRequest(AbstractDeviceHandler.java:97)
at com.fourthpass.wpserver.irm.http.RequestHandler.process(RequestHandler.java:190)
at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doRequest(HttpRequestHandlerServlet.java:128)
at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doGet(HttpRequestHandlerServlet.java:78)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2495)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2204)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Java Stack for "ExecuteThread: '73' for queue: 'default'":
==========
at oracle.jdbc.driver.OracleConnection.getDefaultRowPrefetch(OracleConnection.java:1263)
at oracle.jdbc.driver.OracleStatement.setFetchSize(OracleStatement.java:4878)
at weblogic.jdbc.common.internal.ConnectionEnv.cleanUpStatementForReUse(ConnectionEnv.java:747)
at weblogic.jdbc.common.internal.ConnectionEnv.dropStatement(ConnectionEnv.java:719)
at weblogic.jdbc.jts.Statement.close(Statement.java:231)
at weblogic.jdbc.rmi.internal.StatementImpl.close(StatementImpl.java:97)
at weblogic.jdbc.rmi.SerialStatement.close(SerialStatement.java:123)
at weblogic.jdbc.rmi.SerialStatement.close(SerialStatement.java:113)
at weblogic.ejb20.cmp11.rdbms.PersistenceManagerImpl.releaseStatement(PersistenceManagerImpl.java:596)
at weblogic.ejb20.cmp11.rdbms.PersistenceManagerImpl.releaseResources(PersistenceManagerImpl.java:562)
at weblogic.ejb20.cmp11.rdbms.PersistenceManagerImpl.releaseResources(PersistenceManagerImpl.java:531)
at com.fourthpass.wpserver.billingentities.PendingBillingInfo_6hg1f2__WebLogic_CMP_RDBMS.ejbRemove(PendingBillingInfo_6hg1f2__WebLogic_CMP_RDBMS.java:1135)
at weblogic.ejb20.manager.DBManager.remove(DBManager.java:627)
at weblogic.ejb20.internal.EntityEJBObject.remove(EntityEJBObject.java:117)
at com.fourthpass.wpserver.billingentities.PendingBillingInfoBeanCMP_6hg1f2_EOImpl.remove(PendingBillingInfoBeanCMP_6hg1f2_EOImpl.java:559)
at com.fourthpass.wpserver.billing.BillingBean.movePendingToActiveBilling(BillingBean.java:1442)
at com.fourthpass.wpserver.billing.BillingBean.reportSuccessfulInstallation(BillingBean.java:1349)
at com.fourthpass.wpserver.billing.BillingBean.reportApplicationInstallStatusCode(BillingBean.java:968)
at com.fourthpass.wpserver.billing.BillingBean.reportApplicationInstallStatusCode(BillingBean.java:937)
at com.fourthpass.wpserver.billing.BillingBean_t3moiz_EOImpl.reportApplicationInstallStatusCode(BillingBean_t3moiz_EOImpl.java:1265)
at com.fourthpass.wpserver.handlers.request.mascommands.InstallNotifyCommand.handleOtaEvent(InstallNotifyCommand.java:187)
at com.fourthpass.wpserver.handlers.request.mascommands.InstallNotifyCommand.process(InstallNotifyCommand.java:94)
at com.fourthpass.wpserver.request.handlers.MASRequestHandler.process(MASRequestHandler.java:90)
at com.fourthpass.wpserver.request.RequestProcessorBean.processRequest(RequestProcessorBean.java:113)
at com.fourthpass.wpserver.request.RequestProcessorBean_p612k3_EOImpl.processRequest(RequestProcessorBean_p612k3_EOImpl.java:37)
at com.fourthpass.wpserver.handlers.deviceAdapter.AbstractDeviceHandler.processRequest(AbstractDeviceHandler.java:97)
at com.fourthpass.wpserver.irm.http.RequestHandler.process(RequestHandler.java:190)
at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doRequest(HttpRequestHandlerServlet.java:128)
at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doPost(HttpRequestHandlerServlet.java:89)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2495)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2204)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Found 1 deadlock.

ORACLE 8i - DEADLOCK

Similar Messages

Maybe you are looking for