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

Interface ConnectionProvider

  • All Superinterfaces:
    Serializable, Service, Wrapped
    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 applications to implement its on 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:
    JdbcSettings.CONNECTION_PROVIDER

    • Method Detail

      • 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.