[
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)
