I removed the signal call, with the same results. I can trace the problem to the JobExecutorThread's acquireJobs() method. The job is read from the db, and it is not "exclusive". Because of this, a lock is acquired on the job. I'm perplexed how this will have any bearing on whether the job is executed later or not. It doesn't really matter however, because the next step is to close the jbpmContext. During this process, the thread doesn't return for a minute or so. When it does eventually return, I receive the following exception: | update JBPM_JOB set VERSION_=1, DUEDATE_=2008-10-12 15:41:51.0, PROCESSINSTANCE_=3, TOKEN_=3, | TASKINSTANCE_=null, ISSUSPENDED_=false, ISEXCLUSIVE_=false, LOCKOWNER_='JbpmJobExecutor:10.1.1.22:1', | LOCKTIME_=2008-10-12 15:41:51.009, EXCEPTION_=null, RETRIES_=1, NAME_='timer1', REPEAT_=null, | TRANSITIONNAME_='end', ACTION_=80, GRAPHELEMENTTYPE_='org.jbpm.graph.node.State', GRAPHELEMENT_=82 | where ID_=3 and VERSION_=0 | java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction | at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055) | at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) | at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3491) | at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3423) | at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1936) | at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2060) | at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2542) | at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1734) | at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2019) | at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1937) | at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1922) | at net.sf.log4jdbc.PreparedStatementSpy.executeUpdate(PreparedStatementSpy.java:1006) | at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:102) | at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2435) | at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2335) | at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2635) | at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:115) | at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) | at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) | at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168) | at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) | at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50) | at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1027) | at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:365) | at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:137) | at org.jbpm.persistence.db.DbPersistenceService.commit(DbPersistenceService.java:263) | at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:218) | at org.jbpm.svc.Services.close(Services.java:236) | at org.jbpm.JbpmContext.close(JbpmContext.java:136) | at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:138) | at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:52) | I don't yet understand the transaction boundaries in place in jBPM. Any time DbPersistenceService.getSession() is called, a new transaction is started. When jbpmContext is closed, the sql is flushed, and transactions are commited. Is it possible that the transactions are started, but do not commit in a timely (or balanced) manner? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181712#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...