"dOoMi" wrote : -> resources: i'm sorry, i'm new to the discussion board, too. so i have no idea where to find the original discussion thread. | | -> exception: the exception is caught after all in org.jbpm.svc.Services in Line 226. The original Exception is caught earlier but gets wrapped into a JbpmPersistenceException and is thrown further. | | -> locking-mechanism: you could also use a simple process variable to indicate the locking. as kukeltje stated the problem is the failover-scenario. what happens if the server crashes and the lock stays? | | another approach might be to change the isolaotion-level of the database. this way you could take advantage of the existing locking-mechnism provided by your database. It's good to have you on here dOoMi. Thanks for the info. I didn't think you could use a process variable to do the locking because the contextInstance, in which the variables is stored, is also a shared object like the processInstance. What I did think you could do is create a new task in your process instance that you have to claim and have in your personal task list before you can do anything. This is analogous to claiming a lock. Tasks can have timers so if the server crashes then the timer is still in the database and will eventually timeout. When it times out the task owner will be reset to null. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163616#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...