db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5258) btree post commit releases latch before committing/aborting purges, possibly allowing other operation on page
Date Mon, 06 Jun 2011 18:01:00 GMT

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

Mike Matrigali commented on DERBY-5258:

All the tests passed, and I integrated Bryan's suggested comment changes.  Committed to trunk:
Sending        java\engine\org\apache\derby\impl\store\access\btree\BTreePostCommit.java
Sending        java\engine\org\apache\derby\impl\store\raw\data\BasePage.java
Sending        java\engine\org\apache\derby\impl\store\raw\data\StoredPage.java
Transmitting file data ...
Committed revision 1132711.

> btree post commit releases latch before committing/aborting purges, possibly allowing
other operation on page
> -------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-5258
>                 URL: https://issues.apache.org/jira/browse/DERBY-5258
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:,,,,,,,
>            Reporter: Mike Matrigali
>            Assignee: Mike Matrigali
>             Fix For:
>         Attachments: DERBY-5258_diff.txt
> From code inspection found the following problem.  BTreePostCommit.purgeCommittedDeletes
gives up the latch in it's finally block, before the internal transaction is
> committed.  The transaction is committed no sync upon return from this routine leaving
a very small window when some other thread could get latch on the page and
> perform operations on the page.
> This can be a problem if for some reason the internal transaction is never committed.
 Purges actually return space to the page, unlike deletes.  In order to backout the 
> purges one must add the rows back, taking up space on the page.  If another tranaction
comes in before the internal transaction is committed and does inserts there may
> be no space for the backout of the purges.  This is why normal delete processing only
sets flags on the rows and purge processing is handled differently.  
> I found this problem while debugging a database submitted as part of DERBY-5248.  I believe
this issue can cause the problem there, but since we have no repro have
> decided to create a new issue to target this specific problem/solution.  Later can close
the other issue if it can never be reproduce after the fix.   In DEBY-5248 there 
> are purges without a commit followed immediated by an insert in another transaction that
is commited and the purge transaction is never committed.  On recovery the
> system tries to abort the internal transaction and eventually trashes the page when it
does not actually have enough space to abort the purge.  See that issue for more
> detail.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message