anonymous wrote : but IS it started? Nope. I ran our application in the Eclipse debugger and did not see any reference to LockMonitorThread. I also generated a thread dump of our application, LockMonitorThread does not appear there either. (The dump file is 1800+ lines, I can email it to anybody that is interested in double checking) Note that we are not using a J2EE server. We are running this as a standalone Java application. So with respect to the comment: anonymous wrote : Isn't this the same as transactiontimeouts work in j2ee? Roling back something that just took to long but finished without an error Maybe so, but we aren't using this in a J2EE server. In any case, this isn't a huge issue for us at the moment since we can simply increase the maxLockTime to be the Integer.MAX_VALUE Philosophical commentary follows (feel free to stop reading) So here is my opinion. Any comments and feedback would be appreciated. This is mostly intended to help me understand the jBPM design intent with respect to rolling back successfully completed activities simply because they took too long. So if the node completes succesfully, the transaction shouldn't rollback. Since the timeout doesn't cause the thread (execution context / token) to be aborted the system is doing the work anyhow. You aren't saving anything by considering it a failure. If the intent is that it should be considered an error if a sequence of nodes takes too long to process, then you probably should somehow abort the processing rather than let it continue. Now what would happen (if the LockMonitorThread is actually running) another thread would acquire the job and start running. Now you have two threads actively processing the same path. (Maybe this is a mute point since I think some of the async / JobExecutor stuff is changing post V3.2.1?) Wouldn't be so bad if everything our process did was inside the same database and transaction and didn't have any external side affects that are either difficult or impossible to rollback. So with this behavior we somehow would need to add our own code to test for exceeding maxLockTime and that a rollback was going to occur and we would have to figure out how to detect that jBPM decided to roll things back and compensate or reverse the external actions. For example one of our steps loads millions of rows of data, impractical to have in a single transaction and rollback the data. Our code doesn't get any notification that the rollback occurred so if we have no opportunity to execute compensating code. Maybe the design intent is that everything should be done in such a manner that it is controlled by a transaction monitor. This is generally a bunch of non-trivial work for non-database related activities. So again, I still don't see the value in having a maxLockTime for a job if you are going to let the job run to completion w/o aborting it and allow the system to attempt to process the path again even though it is still currently being processed. This could lead to all kinds of chaos. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084509#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...