com.atlassian.jira.transaction.Transaction |
This represents the state of a running transaction that can be comitted or rolled back
Public Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
This will commit the transaction.
| |||||||||||
This is designed to be called in a top level finally block and it will attempt to rollback the transaction IF it
has not already been committed.
| |||||||||||
Returns if this is a new transaction.
| |||||||||||
This will rollback the transaction.
|
This will commit the transaction.
GenericTransactionException | if the transaction cannot be commited |
---|---|
TransactionRuntimeException |
This is designed to be called in a top level finally block and it will attempt to rollback the transaction IF it has not already been committed. This allows you to simplify your try/catch/finally blocks in and around transaction code.
Note it DOES NOT throw a {@link TransactionRuntimeException) if the roll back cannot be performed. Since this is intended to be inside a finally block it most likely to late to know about this you probably dont want to do anything since rollback hasnt worked either. So it logs this condition is an ignores it to make calling code more simple.
Returns if this is a new transaction. A nested transaction is not new and its behaviour for commit and rollback calls is not performed immediately.
Calls to commit for a nested transaction effectively do nothing relying on the outer transaction to perform the commit.
Calls to rollback for a nested transaction mark the outer transaction as requiring to be rolled back. The outer transaction will eventually rollback, whether commit or rollback is eventually called.
commit()
or rollback()
will actually do anything
This will rollback the transaction.
GenericTransactionException | if the transaction cannot be rollbacked |
---|---|
TransactionRuntimeException |