[esb-issues] [JBoss JIRA] Commented: (JBESB-1438) JMS Courrier does not support transacted mode

[Jiri Pechanec (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBESB-1438?page=comments#action_12396995 ] 
            
Jiri Pechanec commented on JBESB-1438:
--------------------------------------

The problem is that the transaction is committed when it comes to the node Service1 that calls service1.groovy. So it means that if the JMSCourrier sends messages that participates in global transaction. then the message is delivered to queue if and only if  the commit is done in node Service1 after execution of action EsbActionHandler.

You can also change the script that contains Thread.sleep to throw NullPointerException(). In that case the global transaction is rolled-back and the message should never be sent.

I think the gross misunderstanding is due to partly invalid issue description. What I excatly need is that the JMS message sending is enlistened to running XA transaction, whcih is of course different from JMS session transaction mode. Sorry for the confusion.

> JMS Courrier does not support transacted mode
> ---------------------------------------------
>
>                 Key: JBESB-1438
>                 URL: http://jira.jboss.com/jira/browse/JBESB-1438
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Rosetta, Documentation, Examples, Process flow
>    Affects Versions: 4.2.1
>            Reporter: Jiri Pechanec
>         Assigned To: Daniel Bevenius
>            Priority: Blocker
>             Fix For: 4.2.1 CP1
>
>         Attachments: trans.tgz
>
>
> JMS Courrier (deliver side) operates only with non-transacted queue sessions. This prevents jBPM integration to work correctly. The problem can be sketched this way
> 1) The message is received via JMS/JCA listener, transaction is started
> 2) jBPM process is invoked
> 3) jBPM process sends message (calls service) in non-transacted mode
> Three situations can happen
> 1) Exception is thrown later, it means that global transaction is rolled back but another service was already invoked - BUG
> 2) jBPM process goes to the wait state and waits for response from ESB, global transaction is committed, called service sends back signal to continue process - OK
> 3) jBPM process goes to the wait state and waits for response from ESB, called service sends back signal to continue process - but the global transaction was not committed yet - BUG
> This is key feature to have ESB/jBPM integration working safely.

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