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] [Commented] (DERBY-5165) Prepared XA transaction locks are not kept across DB restart
Date Wed, 20 Aug 2014 21:05:27 GMT

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

Mime
View raw message