Interface ConnectionProvider
-
- All Known Implementing Classes:
ConnectionProviderDelegate
,JtaAwareConnectionProviderImpl
,SQLServerSnapshotIsolationConnectionProvider
public interface ConnectionProvider extends Service, Wrapped
A contract for obtaining JDBC connections. Implementors might also implement connection pooling. Implementors should provide a public default constructor.
-
-
Method Summary
All Methods Instance Methods Abstract Methods Modifier and Type Method Description void
closeConnection(java.sql.Connection conn)
Release a connection from Hibernate use.java.sql.Connection
getConnection()
Obtains a connection for Hibernate use according to the underlying strategy of this provider.boolean
supportsAggressiveRelease()
Does this connection provider support aggressive release of JDBC connections and re-acquisition of those connections (if need be) later?-
Methods inherited from interface org.hibernate.service.spi.Wrapped
isUnwrappableAs, unwrap
-
-
-
-
Method Detail
-
getConnection
java.sql.Connection getConnection() throws java.sql.SQLException
Obtains a connection for Hibernate use according to the underlying strategy of this provider.- Returns:
- The obtained JDBC connection
- Throws:
java.sql.SQLException
- Indicates a problem opening a connectionHibernateException
- Indicates a problem otherwise obtaining a connection.
-
closeConnection
void closeConnection(java.sql.Connection conn) throws java.sql.SQLException
Release a connection from Hibernate use.- Parameters:
conn
- The JDBC connection to release- Throws:
java.sql.SQLException
- Indicates a problem closing the connectionHibernateException
- Indicates a problem otherwise releasing a connection.
-
supportsAggressiveRelease
boolean supportsAggressiveRelease()
Does this connection provider support aggressive release of JDBC connections and re-acquisition of those connections (if need be) later? This is used in conjunction withAvailableSettings.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.- Returns:
true
if aggressive releasing is supported;false
otherwise.
-
-