db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4881) Deadlock accessing SYS.SYSSTATISTICS
Date Tue, 02 Nov 2010 13:50:25 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kristian Waagan updated DERBY-4881:
-----------------------------------

    Attachment: derby-4881-1b-deadlock_fix.diff

Thanks for the quick review, Knut Anders :)

Patch 1b is identical to 1a, except that I ditched the changes in FromBaseTable. Avoiding
the second call to statisticsExists is moot because of caching and short-circuiting.

Committed patch 1b to trunk with revision 1030043.

> 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, derby-4881-1b-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.


Mime
View raw message