public interface

ConnectionProvider

org.hibernate.connection.ConnectionProvider
Known Indirect Subclasses

Class Overview

A strategy for obtaining JDBC connections.

Implementors might also implement connection pooling.

The ConnectionProvider interface is not intended to be exposed to the application. Instead it is used internally by Hibernate to obtain connections.

Implementors should provide a public default constructor.

Summary

Public Methods
abstract void close()
Release all resources held by this provider.
abstract void closeConnection(Connection conn)
Dispose of a used connection.
abstract void configure(Properties props)
Initialize the connection provider from given properties.
abstract Connection getConnection()
Grab a connection, with the autocommit mode specified by hibernate.connection.autocommit.
abstract boolean supportsAggressiveRelease()
Does this connection provider support aggressive release of JDBC connections and re-acquistion of those connections (if need be) later?

This is used in conjunction with org.hibernate.cfg.Environment.RELEASE_CONNECTIONS to aggressively release JDBC connections.

Public Methods

public abstract void close ()

Release all resources held by this provider. JavaDoc requires a second sentence.

public abstract void closeConnection (Connection conn)

Dispose of a used connection.

Parameters
conn a JDBC connection
Throws
SQLException

public abstract void configure (Properties props)

Initialize the connection provider from given properties.

Parameters
props SessionFactory properties

public abstract Connection getConnection ()

Grab a connection, with the autocommit mode specified by hibernate.connection.autocommit.

Returns
  • a JDBC connection
Throws
SQLException

public abstract boolean supportsAggressiveRelease ()

Does this connection provider support aggressive release of JDBC connections and re-acquistion of those connections (if need be) later?

This is used in conjunction with org.hibernate.cfg.Environment.RELEASE_CONNECTIONS 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.