public interface MultiTenantConnectionProvider extends Service, Wrapped
| Modifier and Type | Method and Description | 
|---|---|
Connection | 
getAnyConnection()
Allows access to the database metadata of the underlying database(s) in situations where we do not have a
 tenant id (like startup processing, for example). 
 | 
Connection | 
getConnection(String tenantIdentifier)
Obtains a connection for Hibernate use according to the underlying strategy of this provider. 
 | 
void | 
releaseAnyConnection(Connection connection)
Release a connection obtained from  
getAnyConnection() | 
void | 
releaseConnection(String tenantIdentifier,
                 Connection connection)
Release a connection from Hibernate use. 
 | 
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 with  
AvailableSettings.RELEASE_CONNECTIONS
 to aggressively release JDBC connections. | 
isUnwrappableAs, unwrapConnection getAnyConnection() throws SQLException
SQLException - Indicates a problem opening a connectionvoid releaseAnyConnection(Connection connection) throws SQLException
getAnyConnection()connection - The JDBC connection to releaseSQLException - Indicates a problem closing the connectionConnection getConnection(String tenantIdentifier) throws SQLException
tenantIdentifier - The identifier of the tenant for which to get a connectionSQLException - Indicates a problem opening a connectionHibernateException - Indicates a problem otherwise obtaining a connection.void releaseConnection(String tenantIdentifier, Connection connection) throws SQLException
connection - The JDBC connection to releasetenantIdentifier - The identifier of the tenant.SQLException - Indicates a problem closing the connectionHibernateException - Indicates a problem otherwise releasing a connection.boolean supportsAggressiveRelease()
AvailableSettings.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.true if aggressive releasing is supported; false otherwise.Copyright © 2001-2015 Red Hat, Inc. All Rights Reserved.