[jboss-jira] [JBoss JIRA] (JBRULES-3600) DroolsSpringTransactionManager throws NPE instead of handling JPA transaction state

[John Bize (JIRA)]

     [ https://issues.jboss.org/browse/JBRULES-3600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Bize updated JBRULES-3600:
-------------------------------

        Description: 
I posted on this in the forums: https://community.jboss.org/message/751900#751900 but really didn't receive a useful reply.

Since there are clearly bugs in the DroolsSpringTransactionManager, I am posting this bug report too.  I have covered them in the forum post, although I do not know if my mitigating solution is correct even though it seems to work.  

The DroolsSpringTransactionManager has two inherent NullPointerExceptions.  

First, (from my post): There is an obvious bug in the begin() method in that if the call to getStatus() returns STATUS_NO_TRANSACTION, which it will if the wrapped tm (ptm) is null, it immediately dereferences the null ptm. (this.ptm.getTransaction(td)).  I'm not too woried about this one as it seems rather unlikely.

However, the second problem (which affects me) is a NPE masking an IllegalStateException which should probably be caught to return a valid or UNKNOWN state.  The issue (in the getStatus() method) is that it's making the call "transaction = this.ptm.getTransaction(td);" which is occasionally throwing an "IllegalStateException: Transaction already active," wrapped in an outer RuntimeException and dropping down to the finally block (there is no catch).  There, the still null transaction is committed, throwing an NPE that masks the original exception.  To mitigate this, I added a catch RuntimeException and if the cause is an IllegalStateException, I return STATUS_UNKNOWN.  In the finally block, I also ensure that I don't try to commit a null transaction.

A better description of the second bug and mitigation are in the referenced post.

  was:
I posted on this in the forums: https://community.jboss.org/message/751900#751900 but really didn't receive a useful reply.

Since there are clearly bugs in the DroolsSpringTransactionManager, I am posting this bug report too.  I have covered them in the forum post, although I do not no if my mitigating solution is correct even though it seems to work.  

The DroolsSpringTransactionManager has two inherent NullPointerExceptions.  

First, (from my post): There is an obvious bug in the begin() method in that if the call to getStatus() returns STATUS_NO_TRANSACTION, which it will if the wrapped tm (ptm) is null, it immediately dereferences the null ptm. (this.ptm.getTransaction(td)).  I'm not too woried about this one as it seems rather unlikely.

However, the problem I am seeing is a NPE masking an IllegalStateException which should probably be caught to return a valid or UNKNOWN state.  The issue (in the getStatus() method) is that it's making the call "transaction = this.ptm.getTransaction(td);" which is occasionally throwing an "IllegalStateException: Transaction already active," wrapped in an outer RuntimeException and dropping down to the finally block.  There, the still null transaction is committed, throwing an NPE that masks the original exception.  To mitigate this, I added a catch RuntimeException and if the cause is an IllegalStateException, I return STATUS_UNKNOWN.  In the finally block, I also ensure that I don't try to commit a null transaction.

A better description of the second bug and mitigation are in the referenced post.

    Forum Reference: https://community.jboss.org/message/751900#751900  (was: https://community.jboss.org/message/751900#751900)

    
> DroolsSpringTransactionManager throws NPE instead of handling JPA transaction state
> -----------------------------------------------------------------------------------
>
>                 Key: JBRULES-3600
>                 URL: https://issues.jboss.org/browse/JBRULES-3600
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-spring
>    Affects Versions: 5.3.1.Final
>         Environment: RHEL5, Weblogic 10.3.4
>            Reporter: John Bize
>            Assignee: Mark Proctor
>              Labels: jBPM5, spring3
>
> I posted on this in the forums: https://community.jboss.org/message/751900#751900 but really didn't receive a useful reply.
> Since there are clearly bugs in the DroolsSpringTransactionManager, I am posting this bug report too.  I have covered them in the forum post, although I do not know if my mitigating solution is correct even though it seems to work.  
> The DroolsSpringTransactionManager has two inherent NullPointerExceptions.  
> First, (from my post): There is an obvious bug in the begin() method in that if the call to getStatus() returns STATUS_NO_TRANSACTION, which it will if the wrapped tm (ptm) is null, it immediately dereferences the null ptm. (this.ptm.getTransaction(td)).  I'm not too woried about this one as it seems rather unlikely.
> However, the second problem (which affects me) is a NPE masking an IllegalStateException which should probably be caught to return a valid or UNKNOWN state.  The issue (in the getStatus() method) is that it's making the call "transaction = this.ptm.getTransaction(td);" which is occasionally throwing an "IllegalStateException: Transaction already active," wrapped in an outer RuntimeException and dropping down to the finally block (there is no catch).  There, the still null transaction is committed, throwing an NPE that masks the original exception.  To mitigate this, I added a catch RuntimeException and if the cause is an IllegalStateException, I return STATUS_UNKNOWN.  In the finally block, I also ensure that I don't try to commit a null transaction.
> A better description of the second bug and mitigation are in the referenced post.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira