When systems go production sometimes the lock mechanism in the RuntimeManager can be difficult to troubleshot.

Three different flags have been created:

• org.kie.jbpm.runtime.manager.lock.strategy: this allows to select which strategy should be use for all runtime managers created by any runtime manager
• org.kie.jbpm.runtime.manager.lock.factory: this allows to select witch type of lock to be used (normal or debug -diagnostics)
• org.kie.jbpm.runtime.manager.lock.timeout: this allow to specify how long before timeout a timeout lock

This jira is to provide different lock strategies:

• org.jbpm.runtime.manager.impl.lock.FreeRuntimeManagerLockStrategy
  no locks at all. This will lead to optimistic lock failures in db and CPU.
• org.jbpm.runtime.manager.impl.lock.SerializableRuntimeManagerLockStrategy
  perfect serializable locking strategy. It disallows for a runtime manager to access the same process instance id at the same time. lock waits forever till is unlocked. cannot be interrupted or is not affect by Thread.interrupted i.g. tx ThreadReaper
• org.jbpm.runtime.manager.impl.lock.TimeoutRuntimeManagerLockStrategy
  it allows to specify how long a lock should wait before failing. It is recomended: lock timeout < tx timeout.
  It can be affected by Thread.interrupt as well as tx ThreadReaper
• org.jbpm.runtime.manager.impl.lock.InterruptibleRuntimeManagerLockStrategy
  It locks forevever either because it gets the lock or recieves an interrupt signal. It is sensitive to Thread.interrupt and tx ThreadReaper
• org.jbpm.runtime.manager.impl.lock.LegacyRuntimeManagerLockStrategy
  It works with the exact same code as usual

This jira provides also two differet types of lock Default and Debug

• org.jbpm.runtime.manager.impl.lock.DefaultRuntimeManagerLock
  this provides a normal lock
• org.jbpm.runtime.manager.impl.lock.DebugRuntimeManagerLock
  this locks retains information of the current lock and stack trace of all ways the lock reentered keeping such information until is unlocked. This is useful to retain the stack trace and program flow how this lock was acquired by the current owner.
  This is only useful with those locks that are sensitive with interrupt signal or timeout. This information is printed if the current thread is not capable of getting the lock or is being interrupted.