spring-framework / org.springframework.orm.jpa.vendor / HibernateJpaDialect

HibernateJpaDialect

open class HibernateJpaDialect : DefaultJpaDialect

org.springframework.orm.jpa.JpaDialect implementation for Hibernate EntityManager. Developed against Hibernate 5.0/5.1/5.2.

Author
Juergen Hoeller

Author
Costin Leau

Since
2.0

See Also
HibernateJpaVendorAdapterorg.hibernate.Session#setFlushModeorg.hibernate.Transaction#setTimeout

Constructors

<init>

HibernateJpaDialect()

org.springframework.orm.jpa.JpaDialect implementation for Hibernate EntityManager. Developed against Hibernate 5.0/5.1/5.2.

Functions

beginTransaction

open fun beginTransaction(entityManager: EntityManager, definition: TransactionDefinition): Any

cleanupTransaction

open fun cleanupTransaction(transactionData: Any): Unit

getJdbcConnection

open fun getJdbcConnection(entityManager: EntityManager, readOnly: Boolean): ConnectionHandle

prepareTransaction

open fun prepareTransaction(entityManager: EntityManager, readOnly: Boolean, name: String): Any

setPrepareConnection

open fun setPrepareConnection(prepareConnection: Boolean): Unit

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" on Hibernate EntityManager 4.x (with its 'on-close' connection release mode.

If you turn this flag off, JPA transaction management 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.

NOTE: The default behavior in terms of read-only handling changed in Spring 4.1, propagating the read-only status to the JDBC Connection now, analogous to other Spring transaction managers. This may have the effect that you're running into read-only enforcement now where previously write access has accidentally been tolerated: Please revise your transaction declarations accordingly, removing invalid read-only markers if necessary.

translateExceptionIfPossible

open fun translateExceptionIfPossible(ex: RuntimeException): DataAccessException

Inherited Functions

releaseJdbcConnection

open fun releaseJdbcConnection(conHandle: ConnectionHandle, em: EntityManager): Unit

This implementation does nothing, assuming that the Connection will implicitly be closed with the EntityManager.

If the JPA implementation returns a Connection handle that it expects the application to close after use, the dialect implementation needs to invoke Connection.close() (or some other method with similar effect) here.