db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5165) Prepared XA transaction locks are not kept across DB restart
Date Thu, 21 Aug 2014 22:08:11 GMT

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

Myrna van Lunteren updated DERBY-5165:

    Attachment: DERBY-5165Test.diff

Attaching an attempt at a junit test for this.
It only shuts down the database rather than use a forked process but it uses specifically
named singleUse databases which get cleaned up when the test is done.

I made two test cases based on Knut's repro - one using an update which shows the current
problem (with TODO's marking where this test needs to be changed once the bug is fixed), and
one using the insert which shows the expected time-out behavior.

I have not tried to run this in a suite yet.
Test Patch ready for review.

> 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: DERBY-5165Test.diff, 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