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, unwrap
Connection 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 © 2016 JBoss by Red Hat. All rights reserved.