Top Description Constructors Methods
org.hibernate.connection

public Class UserSuppliedConnectionProvider

extends Object
implements ConnectionProvider
Class Inheritance
All Implemented Interfaces
org.hibernate.connection.ConnectionProvider
Imports
java.sql.Connection, java.util.Properties, org.slf4j.LoggerFactory, org.hibernate.HibernateException

An implementation of the ConnectionProvider interface that simply throws an exception when a connection is requested. This implementation indicates that the user is expected to supply a JDBC connection.
Author
Gavin King
See Also
ConnectionProvider

Constructor Summary

AccessConstructor and Description
public

Method Summary

Modifier and TypeMethod and Description
public void
close()

Implements org.hibernate.connection.ConnectionProvider.close.

Release all resources held by this provider.
public void
closeConnection(Connection
a JDBC connection
conn
)

Implements org.hibernate.connection.ConnectionProvider.closeConnection.

Dispose of a used connection.
public void
configure(Properties
SessionFactory properties
props
)

Implements org.hibernate.connection.ConnectionProvider.configure.

Initialize the connection provider from given properties.
public Connection
getConnection()

Implements org.hibernate.connection.ConnectionProvider.getConnection.

Grab a connection, with the autocommit mode specified by hibernate.connection.autocommit.
public boolean
supportsAggressiveRelease()

Implements org.hibernate.connection.ConnectionProvider.supportsAggressiveRelease.

Does this connection provider support aggressive release of JDBC connections and re-acquistion of those connections (if need be) later?
Inherited from java.lang.Object:
cloneequalsfinalizegetClasshashCodenotifynotifyAlltoStringwaitwaitwait

Constructor Detail

UserSuppliedConnectionProviderback to summary
public UserSuppliedConnectionProvider()

Method Detail

closeback to summary
public void close()

Implements org.hibernate.connection.ConnectionProvider.close.

Doc from org.hibernate.connection.ConnectionProvider.close.

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

closeConnectionback to summary
public void closeConnection(Connection conn)

Implements org.hibernate.connection.ConnectionProvider.closeConnection.

Doc from org.hibernate.connection.ConnectionProvider.closeConnection.

Dispose of a used connection.

Parameters
conn:Connection

a JDBC connection

See Also
org.hibernate.connection.ConnectionProvider#closeConnection(Connection)
configureback to summary
public void configure(Properties props) throws HibernateException

Implements org.hibernate.connection.ConnectionProvider.configure.

Doc from org.hibernate.connection.ConnectionProvider.configure.

Initialize the connection provider from given properties.

Parameters
props:Properties

SessionFactory properties

See Also
org.hibernate.connection.ConnectionProvider#configure(Properties)
getConnectionback to summary
public Connection getConnection()

Implements org.hibernate.connection.ConnectionProvider.getConnection.

Doc from org.hibernate.connection.ConnectionProvider.getConnection.

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

Returns:Connection

a JDBC connection

See Also
org.hibernate.connection.ConnectionProvider#getConnection()
supportsAggressiveReleaseback to summary
public boolean supportsAggressiveRelease()

Implements org.hibernate.connection.ConnectionProvider.supportsAggressiveRelease.

Doc from org.hibernate.connection.ConnectionProvider.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.

See Also
ConnectionProvider#supportsAggressiveRelease()