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 and JtaTransactionManager.

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.