Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <4260762.193701288702706416.JavaMail.jira@thor>
Date: Tue, 2 Nov 2010 08:58:26 -0400 (EDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4881) Deadlock accessing SYS.SYSSTATISTICS
In-Reply-To: <21267474.191941288698264585.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

The patch looks good to me. And it removes more code than it adds! :) It looks like Dag handled most of the edges for the read uncommitted case in DERBY-3678, and with your change to ignore td==null, I think it should be safe in the list!=null case too.

I was able to reproduce the deadlock in XplainStatisticsTest on nearly every run with an insane build in my environment. The patch seems to have fixed that, and now I'm not able to reproduce it.

+1 to commit.

> Deadlock accessing SYS.SYSSTATISTICS
> ------------------------------------
>
>                 Key: DERBY-4881
>                 URL: https://issues.apache.org/jira/browse/DERBY-4881
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.0
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>            Priority: Minor
>         Attachments: derby-4881-1a-deadlock_fix.diff
>
>
> Transactions accessing index statistics can deadlock if one of them inserts new entries and the other selects from the system table. Inserts happens for instance when update of index statistics are perform manually, or when a table is compressed (given that the table has indexes and contains some rows). This issue may be more problematic when automatic update of index statistics is implemented.
> Issue discovered when writing a regression tests for DERBY-4849, see discussion there. The bug is timing dependent, but has been observed on a variety of JVMs and platform architectures.
> To sum up:
>   o using NO_WAIT + retry was suggested, but turned out to be an infeasible solution
>   o current approach is to allow using read uncommitted isolation level when accessing statistics in the system table (take no locks)

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