Package org.hibernate.engine.jdbc.connections.spi

Interface ConnectionProvider

All Superinterfaces:
Serializable, Service, Wrapped
All Known Implementing Classes:
DatasourceConnectionProviderImpl, DriverManagerConnectionProviderImpl, UserSuppliedConnectionProviderImpl
public interface ConnectionProvider extends Service, Wrapped
A contract for obtaining JDBC connections and, optionally, for pooling connections.

Implementors must provide a public default constructor.

A ConnectionProvider may be selected using the configuration property "hibernate.connection.provider_class".

It's not usual for an application to implement its own ConnectionProvider. Instead, the Hibernate project provides pre-built implementations for a variety of connection pools as add-on modules.

On the other hand, this is an extremely important extension point for integration with containers and frameworks.

See Also:

  • Method Details

    • getConnection

      Connection getConnection() throws SQLException
      Obtains a connection for Hibernate use according to the underlying strategy of this provider.
      Returns:
      The obtained JDBC connection
      Throws:
      SQLException - Indicates a problem opening a connection
      HibernateException - Indicates a problem otherwise obtaining a connection.

    • closeConnection

      void closeConnection(Connection connection) throws SQLException
      Release a connection from Hibernate use.
      Parameters:
      connection - The JDBC connection to release
      Throws:
      SQLException - Indicates a problem closing the connection
      HibernateException - Indicates a problem otherwise releasing a connection.

    • supportsAggressiveRelease

      boolean supportsAggressiveRelease()
      Does this connection provider support aggressive release of JDBC connections and later re-acquisition of those connections if needed?

      This is used in conjunction with ConnectionReleaseMode.AFTER_STATEMENT to aggressively release JDBC connections. However, the configured ConnectionProvider must support re-acquisition of the same underlying connection for that semantic to work.

      Typically, this is only true in managed environments where a container tracks connections by transaction or thread.

      Note that JTA semantic depends on the fact that the underlying connection provider does support aggressive release.

      Returns:
      true if aggressive releasing is supported; false otherwise.

    • getDatabaseConnectionInfo

      default DatabaseConnectionInfo getDatabaseConnectionInfo(Dialect dialect)
      Returns:
      an informative instance of DatabaseConnectionInfo for logging.
      Since:
      6.6

    • getDatabaseConnectionInfo

      default DatabaseConnectionInfo getDatabaseConnectionInfo(Dialect dialect, ExtractedDatabaseMetaData metaData)
      Returns:
      an informative instance of DatabaseConnectionInfo for logging.
      Since:
      7.0