Currently, if using JobStoreCMT, a user has no choice but to use the database-based StdRowLockSemaphore lock handler. However, if not running clustered, it would be nice to find some way to still use just an in memory locking solution.

The idea is to write a new Semaphore implementation that is JTA Transaction aware.

If it is not in a Transaction, it will behave just as SimpleSemaphore does (for example, acquireNextTrigger()).

However, if it is in a Transaction, it will register a javax.transaction.Synchronization with the enclosing Transaction when obtainLock() is called. This Synchronization's afterCompletion() method will then be responsible for actually releasing the lock, and, when in a JTA Transaction, any other direct calls to releaseLock() will be ignored.

This new Semaphore is experimental, so it will need to be explicitly installed by the user using the "org.quartz.jobStore.lockHandler.class" property.

Because this Semaphore will need to lookup the javax.transaction.TransactionManager in JNDI, and this varies by application server, it will support a "transactionManagerJNDIName" property which defaults to "java:TransactionManager".

Someday, if we start using TransactionManager elsewhere in Quartz we may want to factor out the TransactionManager lookup like UserTransaction so its location is shared.

Also, we could consider looking for the TransactionManager in more than one likely place in JNDI if we aren't explicitly given a location, much like Spring's JtaTransactionManager does.