Class HibernateTransactionManager

    • Constructor Detail

      • HibernateTransactionManager

        public HibernateTransactionManager(SessionFactory sessionFactory)
        Create a new HibernateTransactionManager instance.
        sessionFactory - the SessionFactory to manage transactions for
    • Method Detail

      • setSessionFactory

        public void setSessionFactory(@Nullable
                                      SessionFactory sessionFactory)
        Set the SessionFactory that this instance should manage transactions for.
      • getSessionFactory

        public SessionFactory getSessionFactory()
        Return the SessionFactory that this instance should manage transactions for.
      • obtainSessionFactory

        protected final SessionFactory obtainSessionFactory()
        Obtain the SessionFactory for actual use.
        the SessionFactory (never null)
        java.lang.IllegalStateException - in case of no SessionFactory set
      • setDataSource

        public void setDataSource(@Nullable
                                  javax.sql.DataSource dataSource)
        Set the JDBC DataSource that this instance should manage transactions for. The DataSource should match the one used by the Hibernate SessionFactory: for example, you could specify the same JNDI DataSource for both.

        If the SessionFactory was configured with LocalDataSourceConnectionProvider, i.e. by Spring's LocalSessionFactoryBean with a specified "dataSource", the DataSource will be auto-detected: You can still explicitly specify the DataSource, but you don't need to in this case.

        A transactional JDBC Connection for this DataSource will be provided to application code accessing this DataSource directly via DataSourceUtils or JdbcTemplate. The Connection will be taken from the Hibernate Session.

        The DataSource specified here should be the target DataSource to manage transactions for, not a TransactionAwareDataSourceProxy. Only data access code may work with TransactionAwareDataSourceProxy, while the transaction manager needs to work on the underlying target DataSource. If there's nevertheless a TransactionAwareDataSourceProxy passed in, it will be unwrapped to extract its target DataSource.

        NOTE: For scenarios with many transactions that just read data from Hibernate's cache (and do not actually access the database), consider using a LazyConnectionDataSourceProxy for the actual target DataSource. Alternatively, consider switching "prepareConnection" to false. In both cases, this transaction manager will not eagerly acquire a JDBC Connection for each Hibernate Session anymore (as of Spring 5.1).

        See Also:
        setAutodetectDataSource(boolean), TransactionAwareDataSourceProxy, LazyConnectionDataSourceProxy, JdbcTemplate
      • getDataSource

        public javax.sql.DataSource getDataSource()
        Return the JDBC DataSource that this instance manages transactions for.
      • setAutodetectDataSource

        public void setAutodetectDataSource(boolean autodetectDataSource)
        Set whether to autodetect a JDBC DataSource used by the Hibernate SessionFactory, if set via LocalSessionFactoryBean's setDataSource. Default is "true".

        Can be turned off to deliberately ignore an available DataSource, in order to not expose Hibernate transactions as JDBC transactions for that DataSource.

        See Also:
      • setPrepareConnection

        public void setPrepareConnection(boolean prepareConnection)
        Set whether to prepare the underlying JDBC Connection of a transactional Hibernate Session, that is, whether to apply a transaction-specific isolation level and/or the transaction's read-only flag to the underlying JDBC Connection.

        Default is "true". If you turn this flag off, the transaction manager will not support per-transaction isolation levels anymore. It will not call Connection.setReadOnly(true) for read-only transactions anymore either. If this flag is turned off, no cleanup of a JDBC Connection is required after a transaction, since no Connection settings will get modified.

        See Also:
        Connection.setTransactionIsolation(int), Connection.setReadOnly(boolean)
      • setAllowResultAccessAfterCompletion

        public void setAllowResultAccessAfterCompletion(boolean allowResultAccessAfterCompletion)
        Set whether to allow result access after completion, typically via Hibernate's ScrollableResults mechanism.

        Default is "false". Turning this flag on enforces over-commit holdability on the underlying JDBC Connection (if "prepareConnection" is on) and skips the disconnect-on-completion step.

        See Also:
        Connection.setHoldability(int), ResultSet.HOLD_CURSORS_OVER_COMMIT, disconnectOnCompletion(Session)
      • setHibernateManagedSession

        public void setHibernateManagedSession(boolean hibernateManagedSession)
        Set whether to operate on a Hibernate-managed Session instead of a Spring-managed Session, that is, whether to obtain the Session through Hibernate's SessionFactory.getCurrentSession() instead of SessionFactory.openSession() (with a Spring TransactionSynchronizationManager check preceding it).

        Default is "false", i.e. using a Spring-managed Session: taking the current thread-bound Session if available (e.g. in an Open-Session-in-View scenario), creating a new Session for the current transaction otherwise.

        Switch this flag to "true" in order to enforce use of a Hibernate-managed Session. Note that this requires SessionFactory.getCurrentSession() to always return a proper Session when called for a Spring-managed transaction; transaction begin will fail if the getCurrentSession() call fails.

        This mode will typically be used in combination with a custom Hibernate CurrentSessionContext implementation that stores Sessions in a place other than Spring's TransactionSynchronizationManager. It may also be used in combination with Spring's Open-Session-in-View support (using Spring's default SpringSessionContext), in which case it subtly differs from the Spring-managed Session mode: The pre-bound Session will not receive a clear() call (on rollback) or a disconnect() call (on transaction completion) in such a scenario; this is rather left up to a custom CurrentSessionContext implementation (if desired).

      • setEntityInterceptorBeanName

        public void setEntityInterceptorBeanName(java.lang.String entityInterceptorBeanName)
        Set the bean name of a Hibernate entity interceptor that allows to inspect and change property values before writing to and reading from the database. Will get applied to any new Session created by this transaction manager.

        Requires the bean factory to be known, to be able to resolve the bean name to an interceptor instance on session creation. Typically used for prototype interceptors, i.e. a new interceptor instance per session.

        Can also be used for shared interceptor instances, but it is recommended to set the interceptor reference directly in such a scenario.

        entityInterceptorBeanName - the name of the entity interceptor in the bean factory
        See Also:
        setBeanFactory(org.springframework.beans.factory.BeanFactory), setEntityInterceptor(org.hibernate.Interceptor)
      • setEntityInterceptor

        public void setEntityInterceptor(@Nullable
                                         Interceptor entityInterceptor)
        Set a Hibernate entity interceptor that allows to inspect and change property values before writing to and reading from the database. Will get applied to any new Session created by this transaction manager.

        Such an interceptor can either be set at the SessionFactory level, i.e. on LocalSessionFactoryBean, or at the Session level, i.e. on HibernateTransactionManager.

        See Also:
      • setBeanFactory

        public void setBeanFactory(BeanFactory beanFactory)
        The bean factory just needs to be known for resolving entity interceptor bean names. It does not need to be set for any other mode of operation.
        Specified by:
        setBeanFactory in interface BeanFactoryAware
        beanFactory - owning BeanFactory (never null). The bean can immediately call methods on the factory.
        See Also:
      • afterPropertiesSet

        public void afterPropertiesSet()
        Description copied from interface: InitializingBean
        Invoked by the containing BeanFactory after it has set all bean properties and satisfied BeanFactoryAware, ApplicationContextAware etc.

        This method allows the bean instance to perform validation of its overall configuration and final initialization when all bean properties have been set.

        Specified by:
        afterPropertiesSet in interface InitializingBean
      • isExistingTransaction

        protected boolean isExistingTransaction(java.lang.Object transaction)
        Description copied from class: AbstractPlatformTransactionManager
        Check if the given transaction object indicates an existing transaction (that is, a transaction which has already started).

        The result will be evaluated according to the specified propagation behavior for the new transaction. An existing transaction might get suspended (in case of PROPAGATION_REQUIRES_NEW), or the new transaction might participate in the existing one (in case of PROPAGATION_REQUIRED).

        The default implementation returns false, assuming that participating in existing transactions is generally not supported. Subclasses are of course encouraged to provide such support.

        isExistingTransaction in class AbstractPlatformTransactionManager
        transaction - transaction object returned by doGetTransaction
        if there is an existing transaction
        See Also:
      • doBegin

        protected void doBegin(java.lang.Object transaction,
                               TransactionDefinition definition)
        Description copied from class: AbstractPlatformTransactionManager
        Begin a new transaction with semantics according to the given transaction definition. Does not have to care about applying the propagation behavior, as this has already been handled by this abstract manager.

        This method gets called when the transaction manager has decided to actually start a new transaction. Either there wasn't any transaction before, or the previous transaction has been suspended.

        A special scenario is a nested transaction without savepoint: If useSavepointForNestedTransaction() returns "false", this method will be called to start a nested transaction when necessary. In such a context, there will be an active transaction: The implementation of this method has to detect this and start an appropriate nested transaction.

        Specified by:
        doBegin in class AbstractPlatformTransactionManager
        transaction - transaction object returned by doGetTransaction
        definition - a TransactionDefinition instance, describing propagation behavior, isolation level, read-only flag, timeout, and transaction name
      • doSetRollbackOnly

        protected void doSetRollbackOnly(DefaultTransactionStatus status)
        Description copied from class: AbstractPlatformTransactionManager
        Set the given transaction rollback-only. Only called on rollback if the current transaction participates in an existing one.

        The default implementation throws an IllegalTransactionStateException, assuming that participating in existing transactions is generally not supported. Subclasses are of course encouraged to provide such support.

        doSetRollbackOnly in class AbstractPlatformTransactionManager
        status - the status representation of the transaction
      • doCleanupAfterCompletion

        protected void doCleanupAfterCompletion(java.lang.Object transaction)
        Description copied from class: AbstractPlatformTransactionManager
        Cleanup resources after transaction completion.

        Called after doCommit and doRollback execution, on any outcome. The default implementation does nothing.

        Should not throw any exceptions but just issue warnings on errors.

        doCleanupAfterCompletion in class AbstractPlatformTransactionManager
        transaction - transaction object returned by doGetTransaction
      • disconnectOnCompletion

        protected void disconnectOnCompletion(Session session)
        Disconnect a pre-existing Hibernate Session on transaction completion, returning its database connection but preserving its entity state.

        The default implementation simply calls Session.disconnect(). Subclasses may override this with a no-op or with fine-tuned disconnection logic.

        session - the Hibernate Session to disconnect
        See Also:
      • isSameConnectionForEntireSession

        protected boolean isSameConnectionForEntireSession(Session session)
        Return whether the given Hibernate Session will always hold the same JDBC Connection. This is used to check whether the transaction manager can safely prepare and clean up the JDBC Connection used for a transaction.

        The default implementation checks the Session's connection release mode to be "on_close".

        session - the Hibernate Session to check
        See Also:
      • isPhysicallyConnected

        protected boolean isPhysicallyConnected(Session session)
        Determine whether the given Session is (still) physically connected to the database, that is, holds an active JDBC Connection internally.
        session - the Hibernate Session to check
        See Also: