db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manish Khettry (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2689) Deadlock with GenericPreparedStatement
Date Tue, 26 Jun 2007 21:39:26 GMT

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

Manish Khettry commented on DERBY-2689:
---------------------------------------

Thanks for looking at the patch. 

As far as 2 goes-- if we set "unusedActs" to false at the beginning of the loop and while
trying to close all activations, get an exception won't we end up with the case where unusedActs
= false, yet there are unused activations which the loop did not get to?

For 1, there seems to be no synchronization at all in this class. It is my understanding that
a LangugageConnectionContext is scoped within a connection and only one thread may be using
a lcc at a given time. Is that correct? The only case seems to be the finalize method of ResultSet
which can end up marking "unsedActs".

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;

Can the acts arraylist  bemodified by multiple threads? Also why don't all other routines
employ this extra check? Look for example at lookupCursorActivation, checkIfAnyActivationHasHoldCursor,
verifyAllHeldResultSetsAreClosed among others.

Also, yes there seem to be some wierd characters which have crept up in the comments. I'll
take them out of the next patch.



> 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