db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2689) Deadlock with GenericPreparedStatement
Date Wed, 27 Jun 2007 18:28:26 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508615
] 

Daniel John Debrunner commented on DERBY-2689:
----------------------------------------------

>> On the same note, I'm not sure I understand why we have to do the following:
>>
>> for (int i = acts.size() - 1; i >= 0; i--) {
>>
>> // it maybe the case that a reset() ends up closing
>> // one or more activation leaving our index beyond
>> // the end of the array
>> if (i >= acts.size())
>> continue;
> 
> BaseActivation.close(), which is called further down in the method, calls lcc.removeActivation()
which removes only one activation and should therefore not cause any problems.

I'm not sure that is correct, that a close on an activation only closes one other activation.
Activations can have a relationship to each other, the main case is  a positioned update/delete
on a cursor. Closing the cursor may close the positioned statement. Maybe the code has changed
such that isn't true, but I wanted to throw it out there as an example. The current code is
safe for that situation, so if it is to be changed then that assumption (one close) must be
well documented in the code.

> Deadlock with GenericPreparedStatement
> --------------------------------------
>
>                 Key: DERBY-2689
>                 URL: https://issues.apache.org/jira/browse/DERBY-2689
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.2.2.0
>         Environment: Windows
>            Reporter: Marc Ewert
>            Assignee: Manish Khettry
>            Priority: Critical
>         Attachments: deadlock.patch.txt, TestDerbyPreparedStatements.java
>
>
> We encountered two times a deadlock inside of derby. It seems that we can't workaround
it. The involved two threads are attached, it looks like a classical deadlock:
> "Thread-22" daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry [0x1317f000..0x1317fd4c]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown Source)
> 	- waiting to lock <0x052f4d70> (a org.apache.derby.impl.sql.GenericPreparedStatement)
> 	at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown Source)
> 	at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
Source)
> 	at org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown Source)
> 	at org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown Source)
> 	at org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
Source)
> 	at org.apache.derby.impl.sql.GenericActivationHolder.<init>(Unknown Source)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown Source)
> 	- locked <0x05306f88> (a org.apache.derby.impl.sql.GenericPreparedStatement)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(Unknown Source)
> 	at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
> 	- locked <0x047beb00> (a org.apache.derby.impl.jdbc.EmbedConnection40)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
>         [custom methods]
> "ThreadPoolThread-SyncScheduler-3-1" prio=2 tid=0x0e620400 nid=0xfec waiting for monitor
entry [0x10a7e000..0x10a7fa14]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown Source)
> 	- waiting to lock <0x05306f88> (a org.apache.derby.impl.sql.GenericPreparedStatement)
> 	at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown Source)
> 	at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
Source)
> 	at org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown Source)
> 	at org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown Source)
> 	at org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
Source)
> 	at org.apache.derby.impl.sql.GenericActivationHolder.<init>(Unknown Source)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown Source)
> 	- locked <0x052f4d70> (a org.apache.derby.impl.sql.GenericPreparedStatement)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(Unknown Source)
> 	at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
> 	- locked <0x04225178> (a org.apache.derby.impl.jdbc.EmbedConnection40)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
>         [custom methods]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message