jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Meyer (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2712) Dirty Internal State on Transaction-Rollback during Global Transaction (container managed transaction)
Date Tue, 24 Aug 2010 11:40:27 GMT

    [ https://issues.apache.org/jira/browse/JCR-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901829#action_12901829
] 

Patrick Meyer  commented on JCR-2712:
-------------------------------------

The problem seems to be that ItemStates that are stored in InternalXAVersionmanager are not
rollbacked until the boolean vmgrLocked is true.

see Line 624 of  InternalXAVersionManager last changed by mreutegg in Revision 637865
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalXAVersionManager.java?view=markup
 

This variable can only be true after an prepare Call to the XASession (First Call in 2 Phase
Commit) . But our "rollback trigger" occurs before the call of XASession.prepare.
see Line 654 of InternalXAVersionManager 

The changeset http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalXAVersionManager.java?r1=637864&r2=637865&
checks logging before commit. I think checking vmgrLocked in rollback case is wrong.

Does it have any other side-effect if we remove the check of vmgrLocked in rollback case?
Revision 637865 was for fixing JCR-1480


> 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-jca, transactions
>    Affects Versions: 1.6.2, 2.1.1
>         Environment: Websphere 7 (IBM JRE 6), RessourceAdapter (Jackrabbit), Global Transaction
(JTA)
>            Reporter: Sebastian Sickelmann
>            Priority: Critical
>
> 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