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.
org.hibernate.cfg.AvailableSettings#CONNECTION_PROVIDER
| Modifier and Type | Method and Description |
|---|---|
| public void | closeConnection(Connection
The JDBC connection to release conn)Release a connection from Hibernate use. |
| public Connection | Returns: The obtained JDBC connectionObtains a connection for Hibernate use according to the underlying strategy of this provider. |
| public boolean | Returns: true if aggressive releasing is supported; false otherwise.Does this connection provider support aggressive release of JDBC connections and later re-acquisition of those connections if needed? |
| closeConnection | back to summary |
|---|---|
| public void closeConnection(Connection conn) throws SQLException Release a connection from Hibernate use.
| |
| getConnection | back to summary |
|---|---|
| public Connection getConnection() throws SQLException Obtains a connection for Hibernate use according to the underlying strategy of this provider.
| |
| supportsAggressiveRelease | back to summary |
|---|---|
| public 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 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.
| |