jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JCR-2712) Dirty Internal State on Transaction-Rollback during Global Transaction (container managed transaction)
Date Thu, 23 Sep 2010 10:02:35 GMT

     [ https://issues.apache.org/jira/browse/JCR-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jukka Zitting resolved JCR-2712.
--------------------------------

         Assignee: Jukka Zitting
    Fix Version/s: 2.2.0
       Resolution: Fixed

Thanks for the accurate review of the problem and especially for the test case that made it
easy to reproduce and fix this!

It seems to me that the problem is not that much the vmgrLocked check in the rollback() case,
but rather the fact that the code calling rollback() has not called prepare() first. This
is the case for the UserTransactionImpl utility class in Jackrabbit and apparently also in
some transaction managers. However the InternalXAVersionManager class expects that a commit()
or a rollback() can only happen after prepare() has already been called.

To better handle such situations I modified the InternalXAVersionManager to always make sure
that the transaction is prepared before a commit() or a rollback() is performed. See revision
1000385 for this fix.

> Dirty Internal State on Transaction-Rollback during Global Transaction (container managed
transaction)
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JCR-2712
>                 URL: https://issues.apache.org/jira/browse/JCR-2712
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, jackrabbit-jca, transactions
>    Affects Versions: 1.6.2, 2.1.1
>         Environment: Websphere 7 (IBM JRE 6), RessourceAdapter (Jackrabbit), Global Transaction
(JTA)
>            Reporter: Sebastian Sickelmann
>            Assignee: Jukka Zitting
>            Priority: Critical
>             Fix For: 2.2.0
>
>
> Running the following code inside an Global Transaction (JTA, container managed transaction)
causes problems.
> Session session = getRepsoitorySession(); 
>       Node rootNode = session.getRootNode(); 
>       Node test = rootNode.addNode("test"); 
>       test.addMixin(CTVRepositoryKonstanten.NODE_MIX_TYP_VERSION); 
>       session.save(); 
>       throw new RuntimeException("testException");
> Everythink is fine, but if we execute it a second time we get an org.apache.jackrabbit.core.state.NoSuchItemStateException
> org.apache.jackrabbit.core.state.NoSuchItemStateException: b36d91bc-8687-428c-a767-2e087b13191a

> at org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:270)

> at org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:107)

> at org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:172)

> at org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)

> at org.apache.jackrabbit.core.version.NodeStateEx.store(NodeStateEx.java:519) 
> at org.apache.jackrabbit.core.version.NodeStateEx.store(NodeStateEx.java:489) 
> at org.apache.jackrabbit.core.version.AbstractVersionManager.getParentNode(AbstractVersionManager.java:414)

> at org.apache.jackrabbit.core.version.AbstractVersionManager.createVersionHistory(AbstractVersionManager.java:357)

> at org.apache.jackrabbit.core.version.XAVersionManager.createVersionHistory(XAVersionManager.java:148)

> at org.apache.jackrabbit.core.version.AbstractVersionManager.getVersionHistory(AbstractVersionManager.java:273)

> at org.apache.jackrabbit.core.ItemImpl.initVersionHistories(ItemImpl.java:738) 
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1097) 
> at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:915) 
> at org.apache.jackrabbit.jca.JCASessionHandle.save(JCASessionHandle.java:180) 
> at de.continentale.repo.CTVRepository.erstelleDokument(CTVRepository.java:2267)
> We think that there is some internal state that is not cleaned up on rollback.
> Restarting the runtime (Application Server) "solved" this.
> May be there are some same causes like in: JCR-2503, JCR-2613

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message