[jbossts-issues] [JBoss JIRA] Commented: (JBTM-696) NPE in TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:235)

Andrew Dinn (JIRA) jira-events at lists.jboss.org
Thu Feb 4 06:12:20 EST 2010


    [ https://jira.jboss.org/jira/browse/JBTM-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12510322#action_12510322 ] 

Andrew Dinn commented on JBTM-696:
----------------------------------

Hmm, this is indeed the correct TS for AS 4.2.3.GA. Looking at TwoPhaseCoordinator.java line 235 I notice that the while test refers to synchs.length() rather than copiedSynchs.length() while unsynchronized on synchs. That's clearly a non-threadsafe usage just waiting to blow up and it has in your case.

 I'm also not sure that using synchs itself as the taregt of the synchronized statement (as opposed to an independent lock object) is a good thing since it can be reset to null removing the option of actually taking the relevant lock while it is being nullified. This needs thinking through carefully.



> NPE in TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:235)
> -------------------------------------------------------------------------
>
>                 Key: JBTM-696
>                 URL: https://jira.jboss.org/jira/browse/JBTM-696
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA
>    Affects Versions: 4.2.3.SP7
>         Environment: Linux
>            Reporter: Jörg von Frantzius
>
> In http://community.jboss.org/thread/142942?tstart=0 I've been told that JBOSS 4.2.3GA comes with JBossTS 4.2.3.SP7. 
> We managed to see this exception with JBoss 4.2.3GA :
> Caused by: java.lang.NullPointerException
>         at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:235)
>         at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:86)
>         at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1389)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
>         at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
>         at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:140)
>         at com.artnology.managedobject.impl.ManagedObjectManager.commitUnderlyingTx(ManagedObjectManager.java:5292)
>         at com.artnology.managedobject.impl.ManagedObjectManager.commitTransaction(ManagedObjectManager.java:4838)
> What's a bit unusual about our transaction is that it does a lot of work during beforeCompletion, which might exceed the transaction timeout (but I don't know for sure that it did). Maybe a long user code activity during beforeCompletion can cause this confusion of _synchs possibly already having been nulled out.

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

       



More information about the jbossts-issues mailing list