Supports one resource per key without overwriting, i.e. a resource needs
to be removed before a new one can be set for the same key.
Supports a list of transaction synchronizations if synchronization is active.
Resource management code should check for thread-bound resources, e.g. JDBC
Connections or Hibernate Sessions, via getResource. Such code is
normally not supposed to bind resources to threads, as this is the responsiblity
of transaction managers. A further option is to lazily bind on first use if
transaction synchronization is active, for performing transactions that span
an arbitrary number of resources.
Transaction synchronization must be activated and deactivated by a transaction
manager via initSynchronization and clearSynchronization.
This is automatically supported by AbstractPlatformTransactionManager, and thus
by all standard Spring transaction managers, like DataSourceTransactionManager
Resource management code should only register synchronizations when this
manager is active, which can be checked via isSynchronizationActive;
it should perform immediate resource cleanup else. If transaction synchronization
isn't active, there is either no current transaction, or the transaction manager
doesn't support transaction synchronizations.
Synchronization is for example used to always return the same resources like
JDBC Connections or Hibernate Sessions within a JTA transaction, for any given
DataSource or SessionFactory. In the Hibernate case, the afterCompletion Session
close calls allow for proper transactional JVM-level caching even without a
custom TransactionManagerLookup in Hibernate configuration.