Starts a transaction, calls {@link TransactionWorker#doWork}, and handles transaction retry and exceptions. To perform a transaction, the user implements the {@link TransactionWorker} interface and passes an instance ofthat class to the {@link #run run} method.
A single TransactionRunner instance may be used by any number of threads for any number of transactions.
The behavior of the run() method depends on whether the environment is transactional, whether nested transactions are enabled, and whether a transaction is already active.
- When the run() method is called in a transactional environment and no transaction is active for the current thread, a new transaction is started before calling doWork(). If LockConflictException is thrown by doWork(), the transaction will be aborted and the process will be repeated up to the maximum number of retries. If another exception is thrown by doWork() or the maximum number of retries has occurred, the transaction will be aborted and the exception will be rethrown by the run() method. If no exception is thrown by doWork(), the transaction will be committed. The run() method will not attempt to commit or abort a transaction if it has already been committed or aborted by doWork().
- When the run() method is called and a transaction is active for the current thread, and nested transactions are enabled, a nested transaction is started before calling doWork(). The transaction that is active when calling the run() method will become the parent of the nested transaction. The nested transaction will be committed or aborted by the run() method following the same rules described above. Note that nested transactions may not be enabled for the JE product, since JE does not support nested transactions.
- When the run() method is called in a non-transactional environment, the doWork() method is called without starting a transaction. The run() method will return without committing or aborting a transaction, and any exceptions thrown by the doWork() method will be thrown by the run() method.
- When the run() method is called and a transaction is active for the current thread and nested transactions are not enabled (the default) the same rules as above apply. All the operations performed by the doWork() method will be part of the currently active transaction.
In a transactional environment, the rules described above support nested calls to the run() method and guarantee that the outermost call will cause the transaction to be committed or aborted. This is true whether or not nested transactions are supported or enabled. Note that nested transactions are provided as an optimization for improving concurrency but do not change the meaning of the outermost transaction. Nested transactions are not currently supported by the JE product.
@author Mark Hayes