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] [Updated] (DERBY-5258) btree post commit releases latch before committing/aborting purges, possibly allowing other operation on page
Date Thu, 09 Jun 2011 21:59:59 GMT

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

Mike Matrigali updated DERBY-5258:
----------------------------------

    Fix Version/s: 10.5.3.2

backported from trunk to 10.5 branch with minor conflict fix:

s105_ibm16:18>svn commit

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

> 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: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.1.0, 10.7.1.1,
10.8.1.2
>            Reporter: Mike Matrigali
>            Assignee: Mike Matrigali
>             Fix For: 10.5.3.2, 10.6.2.3, 10.7.1.4, 10.8.1.4, 10.9.0.0
>
>         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

Mime
View raw message