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