Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <2190907.74981276508593879.JavaMail.jira@thor>
Date: Mon, 14 Jun 2010 05:43:13 -0400 (EDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4279) Statement cache deadlock
In-Reply-To: <1442061145.1245454207724.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Knut Anders Hatlen commented on DERBY-4279:
-------------------------------------------

There's a smaller synchronized block within the block where the synchronization is commented out (both synchronized on ps). The inner synchronization was added to address DERBY-3260. The question was raised at that time too, why the synchronization had been commented out in the first place. Since we didn't know why, we went for the minimum needed to fix that bug. Unless there's some change in the patch that makes it necessary to synchronize on the entire block, I'd be more comfortable with leaving the synchronization as it is for now. It's not that I'm 100% convinced the current approach is correct, but if we find problems there, we could address them in a separate issue.

As to multi-threaded access to GenericActivationHolders, I don't think that will happen. I believe GenericActivationHolder instances are private to a transaction, and concurrent access will be prevented by synchronization at a higher level. The instance stored in the ps field can however be shared by multiple GenericActivationHolders, and the synchronization is there to give a consistent view of that object's state.

Another thing that makes me think we should be careful with adding synchronization here, is that it adds to the problem reported in DERBY-3024. I did a few runs on a 32-core machine with the test client attached there, and saw a 10-30% performance degradation for various multi-threaded configurations when the patch was applied.

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