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