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 16:58:26 GMT

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

Mike Matrigali commented on DERBY-5165:

probably not going to have much luck getting this to work in the "default" configuration,
also not going to run well repeated without some coding for unique XA XID's.  The caller provides
the XA XID's so if test is to be run multiple times in same db, the test will have to figure
out a way
to provide unique ones each time.

I would make first step to get test to run ONCE as a simple junit test, and it should  create
and destroy
it's own database as part of its work.  It should use the code that was added to allow tests
to run in 
separate process to a point, then crash to exercise recovery, and come back up and test after
I know tests were added to use some infrastructure for this in the past, looking for the example.

> 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