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-5165) Prepared XA transaction locks are not kept across DB restart
Date Wed, 20 Aug 2014 21:39:26 GMT

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

Mike Matrigali commented on DERBY-5165:

if original test shuts down cleanly and repro's then forced crash not necessary.  Though doing
a forced crash as an add on test might be interesting, just to verify that works too.

In the real world JVM's running derby crash all the time (really more likely exited by some
non-derby thread of control), so the more testing we do with JVM's shutting down without clean
shutdown the better.  But first off better to just get the test to show what you want, and
it seems like crash not necessary.  I often just use the word crash when I am thinking about
a derby db going down not cleanly such that there is work for 
recovery to do when it comes up.  XA is an interesting case in that even if you shut down
cleanly there may be work to do in recovery.

For this specific bug it is Derby's job on reboot to reclaim all the locks on all the changed
data of any XA transaction that is in prepared but uncommitted state.  In some cases as pointed
out by this bug Derby is not doing that.

> Prepared XA transaction locks are not kept across DB restart
> ------------------------------------------------------------
>                 Key: DERBY-5165
>                 URL: https://issues.apache.org/jira/browse/DERBY-5165
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:
>         Environment: Mac OSX 
>            Reporter: Guy Pardon
>            Assignee: Mike Matrigali
>              Labels: derby_triage10_11
>         Attachments: Derby5165.java
> Steps to reproduce:
> 1-perform update with XA, using, say Xid xid1
> 2-prepare xid1 with XA but do NOT commit
> 3-restart Derby DB
> 4-the updates of step 1 will be visible
> When xid1 is rolled back after step 3 then the updates are gone. So my conclusion is
that the transaction is not committed yet, but the updates are visible after prepare. This
is a violation of the XA semantics.

This message was sent by Atlassian JIRA

View raw message