-
15. Re: JBPM - concurrent process execution fails
efip10,
On thinking about your problem some more...
Are you using JTA transactions?
AFAIK, an MDB message sent as part of a JTA transaction will not actually be sent until the transaction is committed. In this case, if the MDB were created as part of the transaction that's saving the ProcessInstance, it wouldn't be able to fire until after the ProcessInstance has been fully saved.
In this context, my earlier suggestion to use "async=true" may be whacked - it opens a race condition that need not exist!
I wonder if there's something in your transaction configuration that could be better.
I'm no pro in this area - suspect everything I say is wrong! ;-)
-Ed Staub -
16. Re: JBPM - concurrent process execution fails
Ed,
I am not sure that you have a point here, as JTA can only guarantee the fact, not the order. I.e. it is either (the rows are saved && JMS message is sent) or (the rows are ! saved && JMS message is ! sent). However, JTA cannot guarantee the order (first the rows are saved, then the message is sent, or any other order).
If it wasn't like this, one would be able to come up with a scenario - let's say, save row, send message, save second row, send second message. Anyone who would base on the fact that the second row *is not* in the db yet when the first message has arrived, would find himself in a race condition.
I ain't no pro either, and I'd be happy to be wrong here. -
17. Re: JBPM - concurrent process execution fails
efip10,
Sorry, I used too broad a brush.
At least in some cases, the behavior I described is dependent on the isolation level selected. If at least level 2 ("read-committed") is selected, then I think it works as I described, if the database supports it. I believe that row-locking is used internally to the database to prevent concurrent access during the commit. Everything is written first, and then everything is unlocked. Thus if the race goes the wrong way, the early reader will block until the late writer has finished. I don't know about MySQL's behavior in this area.
While I think that JBPM is supposed to work
with any isolation level, its default isolation level is 1 ("read-uncommitted"), and so there's much more experience with that level. The level for JBPM is set as hibernate property hibernate.connection.isolation. I don't know where isolation level for a database-persisted queue is dealt with for JMS - AFAICT, it's either vendor-specific, or it's automatically set to "read-committed" if this isolation level is supported. For JBoss messaging, I haven't found where it's set, but see http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/guide/html_single/index.html#startingtheservice for more info. I don't know how current it is.
Please share back whatever you find out!
-Ed Staub -
18. Re: JBPM - concurrent process execution fails
JBPM use Hibernate to write to the DB, Even if the transactin is NOT_SUPPORTED it not write immedetly to the DB but rather wait for flush to write to the DB. In some cases the Hibernate session of JBPM is different than the Hibernate session of the application.
Therefore if JBPM needs to write something to the DB and then there is asynchronus call in different thread in which JBPM read from the DB, the read may be perform before the write.
In this case there is need to flush the the two sessions before inovking the aysnchronus call, the JBPM session and the application session.
The JBPM Hibernate session can be flushed by calling:
ctx.getJbpmContext().getSession().flush();
ctx is the execution context