@ProviderType public abstract class TransactionBuilder extends Object implements TransactionStarter
Modifier and Type | Field and Description |
---|---|
protected List<Class<? extends Throwable>> |
noRollbackFor
The list of
Throwable types that must not trigger rollback |
protected List<Class<? extends Throwable>> |
rollbackFor
The list of
Throwable types that must trigger rollback |
Constructor and Description |
---|
TransactionBuilder() |
Modifier and Type | Method and Description |
---|---|
TransactionBuilder |
noRollbackFor(Class<? extends Throwable> t,
Class<? extends Throwable>... throwables)
Declare a list of Exception types (and their subtypes) that must
not trigger a rollback.
|
abstract TransactionBuilder |
readOnly()
Indicate to the Transaction Control service that this transaction will be
read-only.
|
TransactionBuilder |
rollbackFor(Class<? extends Throwable> t,
Class<? extends Throwable>... throwables)
Declare a list of Exception types (and their subtypes) that must
trigger a rollback.
|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
notSupported, required, requiresNew, supports
protected final List<Class<? extends Throwable>> rollbackFor
Throwable
types that must trigger rollback@SafeVarargs public final TransactionBuilder rollbackFor(Class<? extends Throwable> t, Class<? extends Throwable>... throwables)
Exception
s. If a more specific type is registered using
noRollbackFor(Class, Class...)
then that type will not trigger
rollback. If the same type is registered using both
rollbackFor(Class, Class...)
and
noRollbackFor(Class, Class...)
then the transaction will
not begin and will instead throw a TransactionException
Note that the behavior of this method differs from Java EE and Spring in two ways:
rollbackFor
and noRollbackFor
. Stating that the same
Exception should both trigger and not trigger rollback is a
logical impossibility, and clearly indicates an API usage error. This API
therefore enforces usage by triggering an exception in this invalid case.
t
- throwables
- The Exception types that should trigger rollback@SafeVarargs public final TransactionBuilder noRollbackFor(Class<? extends Throwable> t, Class<? extends Throwable>... throwables)
Exception
s. If an Exception type is registered using this
method then that type and its subtypes will not trigger
rollback. If the same type is registered using both
rollbackFor(Class, Class...)
and
noRollbackFor(Class, Class...)
then the transaction will
not begin and will instead throw a TransactionException
Note that the behavior of this method differs from Java EE and Spring in two ways:
rollbackFor
and noRollbackFor
. Stating that the same
Exception should both trigger and not trigger rollback is a
logical impossibility, and clearly indicates an API usage error. This API
therefore enforces usage by triggering an exception in this invalid case.
t
- An exception type that should not trigger rollbackthrowables
- further exception types that should not trigger
rollbackpublic abstract TransactionBuilder readOnly()
Note that this method is for optimization purposes only. The TransactionControl service is free to ignore the call if it does not offer read-only optimization.
If a transaction is marked read-only and then the scoped work performs a write operation on a resource then this is a programming error. The resource is free to raise an exception when the write is attempted, or to permit the write operation. As a result the transaction may commit successfully, or may rollback.
Copyright © Contributors to the Eclipse Foundation Licensed under the Eclipse Foundation Specification License – v1.0