[
https://issues.apache.org/jira/browse/DERBY-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877821#action_12877821
]
Brett Wooldridge commented on DERBY-4279:
-----------------------------------------
Hi Knut, thanks for taking a look.
1) The synchronized block in GenericActivationHolder.execute() was actually
completely commented out in the original -- but the comment regarding the
synchronized block remained. I'm actually unsure if there is indeed
multi-threaded access to GenericActivationHolder -- but I believe there can be.
Because that method replaces several member variables, it seems unsafe to do
so outside of the context of a synchronized block. So, basically I just
restored the synchronized block. If it can be shown that there is no
multi-threaded access -- for example because of a lock higher up the call
chain, we can certainly remove it. But being unfamiliar with the Derby
codebase in general, I decided to err on the side of caution.
2) My thinking on removing the statement from the cache was that the new
statement is an equal candidate to be cached, and because it was just
recompiled the one that does exist in the cache is stale in a sense.
3) I thought that too. I think it would indeed be safe to remove to calls to
notifyAll(), at least in the case of GenericStatement.
> 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.0.2.1, 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0,
> 10.5.1.1
> Environment: Windows Vista
> Reporter: Jeff Stuckman
> Assignee: Brett Wooldridge
> Attachments: Derby4279.java, patch4279.txt
>
>
> 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.
