The reason for using transacted JMS sessions is participating in global
transactions when they are present, or commit/rollback at the same time the
database transaction does.
When a listener receives a message, it begins a transaction, resumes the
execution of the process instance until nothing more can be done, and then
commits the transaction. That's why you get the reply when you introduce an
inbound message activity. The "missing" session.commit() is, in fact, in
RequestListener:
public void onMessage(Message request) {
| [...]
| MessagerSession messagerSession = this.messagerSession;
| JbpmSession jbpmSession =
messager.getJbpmSessionFactory().openJbpmSession();
| org.hibernate.Session hibSession = jbpmSession.getSession();
|
| Transaction tx = null;
| try {
| // start transaction to deliver request
| tx = hibSession.beginTransaction();
|
| // reload persistent objects
| Receiver receiver = (Receiver) hibSession.load(Receiver.class, new
Long(receiverId));
| Token token = (Token) hibSession.load(Token.class, new Long(tokenId));
| [...]
| // pass message content to the activity
| Element messageElem = (Element) ((ObjectMessage)
request).getObject();
| InboundMessageListener listener =
receiver.getInboundMessageListener();
| listener.messageReceived(receiver, messageElem, token);
| [...]
| // commit transaction to deliver request
| if (!messager.isDistributed())
messagerSession.getJmsSession().commit();
| tx.commit();
| }
| catch (Throwable e) {
| [...]
| // rollback jms transaction
| if (!messager.isDistributed()) {
| try {
| messagerSession.getJmsSession().rollback();
| }
| catch (JMSException re) {
| log.warn("could not rollback jms session", re);
| }
| }
| // rollback db transaction
| if (tx != null) tx.rollback();
| }
| finally {
| jbpmSession.close();
| }
| }
I agree you could have complex processing after the reply activity and you want
the message to leave as soon as it is ready. I can think of two alternatives:
Have the option to send the reply immediately, altough the ongoing transaction
might be rolled back later. The client would receive a timely response, and be
surprised in the future that the expected changes in the state of the process
are not reflected.
Commit the transaction(s) and restart new one(s). This would result in a timely
and reliable response, but consumes more resources and is unnecesary for many
processes (isn't that the eternal argument against transactions?). In fact, it
only makes sense for global transactions, as the separation of local db/jms
transactions would produce inconsistent results in the event of failure anyway.
What behavior would you prefer to see?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3922417#3922417
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3922417
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user
