Abstract base class that allows for easy implementation of concrete
platform transaction managers like JtaTransactionManager and
DataSourceTransactionManager.
This base class provides the following workflow handling:
determines if there is an existing transaction;
applies the appropriate propagation behavior;
suspends and resumes transactions if necessary;
checks the rollback-only flag on commit;
applies the appropriate modification on rollback
(actual rollback or setting rollback-only);
triggers registered synchronization callbacks
(if transaction synchronization is active).
Subclasses have to implement specific template methods for specific
states of a transaction, for example begin, suspend, resume, commit, rollback.
The most important of them are abstract and must be provided by a concrete
implementation; for the rest, defaults are provided, so overriding is optional.
Transaction synchronization is a generic mechanism for registering callbacks
that get invoked at transaction completion time. This is mainly used internally
by the data access support classes for JDBC, Hibernate, and JDO when running
within a JTA transaction: They register resources that are opened within the
transaction for closing at transaction completion time, allowing e.g. for reuse
of the same Hibernate Session within the transaction. The same mechanism can
also be leveraged for custom synchronization needs in an application.
The state of this class is serializable, to allow for serializing the
transaction strategy along with proxies that carry a transaction interceptor.
It is up to subclasses if they wish to make their state to be serializable too.
They should implement the java.io.Serializable marker interface in
that case, and potentially a private readObject() method (according
to Java serialization rules) if they need to restore any transient state.
This base class provides the following workflow handling:
Subclasses have to implement specific template methods for specific states of a transaction, for example begin, suspend, resume, commit, rollback. The most important of them are abstract and must be provided by a concrete implementation; for the rest, defaults are provided, so overriding is optional.
Transaction synchronization is a generic mechanism for registering callbacks that get invoked at transaction completion time. This is mainly used internally by the data access support classes for JDBC, Hibernate, and JDO when running within a JTA transaction: They register resources that are opened within the transaction for closing at transaction completion time, allowing e.g. for reuse of the same Hibernate Session within the transaction. The same mechanism can also be leveraged for custom synchronization needs in an application.
The state of this class is serializable, to allow for serializing the transaction strategy along with proxies that carry a transaction interceptor. It is up to subclasses if they wish to make their state to be serializable too. They should implement the
java.io.Serializablemarker interface in that case, and potentially a privatereadObject()method (according to Java serialization rules) if they need to restore any transient state.