[
http://jira.jboss.com/jira/browse/JBESB-1438?page=comments#action_12396993 ]
Daniel Bevenius commented on JBESB-1438:
----------------------------------------
I've made a few changes to the code to make sure that the JMSCourier infact does use
transacted session for picking up messages and for sending messages.
But I don't understand how the quickstart is supposed to prove that transaction are
working properly with jBPM.
This is my understanding of the quickstart:
1. 'ant startProcess' create a file that is picked up by the file gateway.
2. The file contents is packaged and sent via a JMSCourier that is transacted.
3. Action pipeline is invoked and "MessageSpy: Body: Start it up" is printed.
4. jBPM process "processDefinition2" is started by in action pipleline.
1. start-state has a transition to "node1". The transistion contains an
action named "action1".
action1 calls the ESB Service "Service0" which uses a JMSCourier that is
transacted.
Service0 executes /scripts/service0.groovy and prints:
"********** This should be second ***********"
2. node1 is entered and its "node-enter" event is executed.
The "node-enter" event will sleep(5000) and then prints "***** This
should be first *****"
Next the action of node1 will be executed and call Service1 using a JMSCourier
that is transacted.
Service1 executes executes /scripts/service1.groovy
...
Sorry if I missing something obvious here but I can't see how this proves that
transactions are working of not.
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