db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Stuckman (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4279) Statement cache deadlock
Date Fri, 19 Jun 2009 23:34:07 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722088#action_12722088
] 

Jeff Stuckman commented on DERBY-4279:
--------------------------------------

Output from test case:

Invalidating the prepared statements...
Table locked.
Executing query 1. Query should block because other thread has lock.
Executing query 2. Query should not block because this thread already has the necessary locks.
java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested
	at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
	at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown Source)
	at Derby4279$Thread2.run(Derby4279.java:81)
	at java.lang.Thread.run(Thread.java:619)
Caused by: java.sql.SQLException: A lock could not be obtained within the time requested
	at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
Source)
	... 11 more
Caused by: ERROR 40XL1: A lock could not be obtained within the time requested
	at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
	at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown Source)
	at org.apache.derby.impl.services.locks.AbstractPool.lockObject(Unknown Source)
	at org.apache.derby.impl.services.locks.ConcurrentPool.lockObject(Unknown Source)
	at org.apache.derby.impl.store.raw.xact.RowLocking2.lockContainer(Unknown Source)
	at org.apache.derby.impl.store.raw.data.BaseContainerHandle.useContainer(Unknown Source)
	at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown Source)
	at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown Source)
	at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown Source)
	at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(Unknown Source)
	at org.apache.derby.impl.store.access.heap.Heap.open(Unknown Source)
	at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(Unknown Source)
	at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(Unknown Source)
	at org.apache.derby.impl.sql.compile.ResultColumnList.generateHolderMethod(Unknown Source)
	at org.apache.derby.impl.sql.compile.FromBaseTable.getScanArguments(Unknown Source)
	at org.apache.derby.impl.sql.compile.FromBaseTable.generateResultSet(Unknown Source)
	at org.apache.derby.impl.sql.compile.FromBaseTable.generate(Unknown Source)
	at org.apache.derby.impl.sql.compile.IndexToBaseRowNode.generate(Unknown Source)
	at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(Unknown Source)
	at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(Unknown Source)
	at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(Unknown Source)
	at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(Unknown Source)
	at org.apache.derby.impl.sql.compile.ScrollInsensitiveResultSetNode.generate(Unknown Source)
	at org.apache.derby.impl.sql.compile.CursorNode.generate(Unknown Source)
	at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown Source)
	at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
	at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
	at org.apache.derby.impl.sql.GenericPreparedStatement.rePrepare(Unknown Source)
	... 5 more
Query 2 finished.


> Statement cache deadlock
> ------------------------
>
>                 Key: DERBY-4279
>                 URL: https://issues.apache.org/jira/browse/DERBY-4279
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.5.1.1
>         Environment: Windows Vista
>            Reporter: Jeff Stuckman
>
> Due to a design flaw in the statement cache, a deadlock can occur if a prepared statement
becomes out-of-date.
> I will illustrate this with the following example:
> The application is using the embedded Derby driver. The application has two threads,
and each thread uses its own connection.
> There is a table named MYTABLE with column MYCOLUMN.
> 1. A thread prepares and executes the query SELECT MYCOLUMN FROM MYTABLE. The prepared
statement is stored in the statement cache (see org.apache.derby.impl.sql.GenericStatement
for this logic)
> 2. After some time, the prepared statement becomes invalid or out-of-date for some reason
(see org.apache.derby.impl.sql.GenericPreparedStatement)
> 3. Thread 1 begins a transaction and executes LOCK TABLE MYTABLE IN EXCLUSIVE MODE
> 4. Thread 2 begins a transaction and executes SELECT MYCOLUMN FROM MYTABLE. The statement
is in the statement cache but it is out-of-date. The thread begins to recompile the statement.
To compile the statement, the thread needs a shared lock on MYTABLE. Thread 1 already has
an exclusive lock on MYTABLE. Thread 2 waits.
> 5. Thread 1 executes SELECT MYCOLUMN FROM MYTABLE. The statement is in the statement
cache but it is being compiled. Thread 1 waits on the statement's monitor.
> 6. We have a deadlock. Derby eventually detects a lock timeout, but the error message
is not descriptive. The stacks at the time of the deadlock are:
> This deadlock is unique because it can still occur in a properly designed database. You
are only safe if all of your transactions are very simple and cannot be interleaved in a sequence
that causes the deadlock, or if your particular statements do not require a table lock to
compile. (For the sake of simplicity, I used LOCK TABLE in my example, but any UPDATE statement
would fit.)

-- 
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