[jira] [Updated] (DERBY-5165) Prepared XA transaction locks are not kept across DB restart

["Myrna van Lunteren (JIRA)" <ji...@apache.org>]

     [ 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: 10.6.2.1
>         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
(v6.2#6252)