[ http://issues.apache.org/jira/browse/JCR-566?page=all ]

Florent Guillaume updated JCR-566:
----------------------------------

    Attachment: debug1.py

Attaching jython program used to demonstrate the bug.
This is with Jython 2.1 and
  java version "1.5.0_06"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)
  Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing)
(on Mac OS X 10.4)


> Versioning bug with restore and transactions
> --------------------------------------------
>
>                 Key: JCR-566
>                 URL: http://issues.apache.org/jira/browse/JCR-566
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: transactions
>    Affects Versions: 1.1
>            Reporter: Florent Guillaume
>         Attachments: debug1.py
>
>
> This is a versioning bug in the presence of restore and transactions. It's 
> hard to reproduce and seems memory-layout dependent.
> At the moment I only have a jython testcase, see below. This is with a svn 
> checkout from today (442228).
> Basically the program does create a node and subnode and do some checkins, 
> checkouts, restore, modifications, in successive transactions. Transactions 
> are managed manually using the xaresource API, but it would be equivalent to 
> use a UserTransaction (the sequence of xaresource calls in the end is the 
> same).
> The program log and stack trace is: 
> start 1
> node 36eca6a5-8e5d-46a8-897a-4b81734aaad4
> commit 1
> start 2
> commit 2
> start 3
> commit 3
> javax.transaction.xa.XAException
>         at 
> org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:138)
>         at 
> org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:300)
>         File "debug1.py", line 128, in doit
>         File "debug1.py", line 145, in ?
> Caused by: org.apache.jackrabbit.core.TransactionException: Unable to prepare 
> transaction.
>         at 
> org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:159)
>         at 
> org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:121)
>         ... 22 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: 
> 36eca6a5-8e5d-46a8-897a-4b81734aaad4/{http://www.jcp.org/jcr/1.0}predecessors 
> has been modified externally
>         at 
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:546)
>         at 
> org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:717)
>         at 
> org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:151)
>         ... 23 more
> javax.transaction.xa.XAException: javax.transaction.xa.XAException
> Note that the mentionned property (here, "jcr:predecessors") has changed when 
> I was cutting down on the program size to get a simpler testcase. It's not 
> necessarily a "system" property, and sometimes it was property of the subnode 
> created under the main node.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to