[ 
https://issues.apache.org/jira/browse/DERBY-5165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14104649#comment-14104649
 ] 

Mike Matrigali commented on DERBY-5165:
---------------------------------------

if original test shuts down cleanly and repro's then forced crash not 
necessary.  Though doing a forced crash as an add on test might be interesting, 
just to verify that works too.

In the real world JVM's running derby crash all the time (really more likely 
exited by some non-derby thread of control), so the more testing we do with 
JVM's shutting down without clean shutdown the better.  But first off better to 
just get the test to show what you want, and it seems like crash not necessary. 
 I often just use the word crash when I am thinking about a derby db going down 
not cleanly such that there is work for 
recovery to do when it comes up.  XA is an interesting case in that even if you 
shut down cleanly there may be work to do in recovery.

For this specific bug it is Derby's job on reboot to reclaim all the locks on 
all the changed data of any XA transaction that is in prepared but uncommitted 
state.  In some cases as pointed out by this bug Derby is not doing 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)

Reply via email to