[
https://issues.apache.org/jira/browse/DERBY-5165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14104574#comment-14104574
]
Myrna van Lunteren commented on DERBY-5165:
-------------------------------------------
Thanks for your input Mike.
I was trying to add this as a test case to jdbcapi.XATransactionTest because it
seemed similar to various other test cases in that class, but I'll move it to
its own class and use a singleUseDatabase Decorator.
I worry that this will still hold resources after the test is done, but at
least it won't affect other tests like it's doing now.
I am wondering though if a forced crash by a forked jvm process is needed? The
steps in the description just says to restart the database, and Knut's repro
shuts down the database and that reproduces the behavior, would that be
sufficient?
The reason for minimizing use of the construct/mechanism of OCRecoveryTest is
that it uses textui.TestRunner -m option which is not something that can be
upgraded to JUNIT 4 - (in case we ever do that).
> 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)
