org.hibernate.connection
Interface ConnectionProvider
- DatasourceConnectionProvider, DriverManagerConnectionProvider, UserSuppliedConnectionProvider
public interface ConnectionProvider
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.
void | close() - Release all resources held by this provider.
|
void | closeConnection(Connection conn) - Dispose of a used connection.
|
void | configure(Properties props) - Initialize the connection provider from given properties.
|
Connection | getConnection() - Grab a connection, with the autocommit mode specified by
hibernate.connection.autocommit.
|
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.
|
close
public void close()
throws HibernateException
Release all resources held by this provider. JavaDoc requires a second sentence.
closeConnection
public void closeConnection(Connection conn)
throws SQLException
Dispose of a used connection.
configure
public void configure(Properties props)
throws HibernateException
Initialize the connection provider from given properties.
props
- SessionFactory properties
getConnection
public Connection getConnection()
throws SQLException
Grab a connection, with the autocommit mode specified by
hibernate.connection.autocommit.
supportsAggressiveRelease
public 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.