"tom.baeyens(a)jboss.com" wrote : in a persistent environment, jBPM synchronizes on the database. What behaviour should I expect in this case? I would expect that a select on a table where a write-transaction from another thread is open should block until the transaction is ended (It might also throw something like a ConcurrentAccessException to indicate the access conflict). Looking at my problem, this should cause the second thread to block until the first transaction is commited, but instead second thread is not block (or receives an "concurrent access exception"), which I would expect, instead it returns data (directly from the DB?) which conflicts with data held in another thread (out of sync data). anonymous wrote : | you'll get your concurrency from your environment (ejbs, mdbs, web app and the likes) note that when moving transactional from one wait state to the next, jBPM synchronizes on the DB, so transactions should be handled concurrently, but inside one transaction, no multi threading is needed. Does that mean that the jBPM keeps one transaction open from ending one task until wait() in the next task? Will an error in task-assign also rollback the task-end (node-leave) of the previous node? And when is the task-assign event handling triggered? I assumed that the first transaction (Thread A) should be ended before sending the events (because the event handlers already receive a fixed task assignment). The event actions then would have to create more transactions if they need them, but the task instance assignment BTW: My setup is a standalone jBPM (with in-memory sql database), no ejbs, jboss container, .. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025387#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...