In the current WebSphere Application Server programming model, you can
specify one Container-Managed Persistence (CMP) connection factory, which
corresponds to one datasource for one CMP enterprise bean. Under the new proxy
datasource support, one CMP connection factory is specified for one CMP enterprise
bean. However, during runtime, this proxy datasource will route the connection
requests to different underlying datasources.
The underlying datasource the proxy datasource will route to is decided
by the application. At the beginning of every transaction, you can use WebSphere
Extended Deployment specific API to specify which underlying datasource this
current transaction will use.
Following is the general programming model for the proxy datasource support:
- Application developers use a session enterprise bean as the session facade.
The session enterprise bean is required to use CMP enterprise bean local interfaces
to interact with CMP enterprise beans.
- Application developers or assemblers define all the resource references
for CMP enterprise bean persistence in the session enterprise bean. For example,
if you expect your CMP enterprise beans will be persisted in three different
database servers, you should create three different resource (datasource)
reference names.
- Create the datasources. Creating the datasources consists of two steps:
creating all underlying datasources and creating the proxy datasource. The
application deployer creates datasources for all of the database servers used
for CMP EJB persistence in the WebSphere administration space. For example,
the deployer creates four datasources for three different database servers
with JNDI name jdbc/WestAccountDS, jdbc/EastAccountDS, jdbc/NorthAccountDS,
and jdbc/SouthAccountDS. The application deployer then creates a
proxy datasource using the proxy DataSource JDBC provider or proxy DataSource
JDBC provider (XA) provided only in WebSphere Extended Deployment. In the
customer property jndiNames of the proxy datasource, the deployer add the
JNDI names of all the datasources just defined in the format of dsJNDIName_1;dsJNDIName_2;
dsJNDIName_3… dsJNDIName_N. In this example, the jndiNames will be set
to:
jdbc/WestAccount;jdbc/EastAccount;jdbc/NorthAccount;jdbc/SouthAccount
- In the enterprise bean applications, application developers provide a
mapping for CMP enterprise bean attributes (one or more attributes) to the
resource references defined in the session enterprise beans. This mapping
can be stored in an Extensible Markup Language (XML) database, property file,
or even programmatically. Based on this mapping, the developer knows which
datasource a transaction should use. The following is an example of creating
mapping programmatically:
if (accountId.startsWith("w")) {
return resrefs[0];
}
else if ((accountId.startsWith("e")) {
return resrefs [1];
}
else if ((accountId.startsWith("n")) {
return resrefs [2];
}
else if ((accountId.startsWith("s")) {
return resrefs [3];
}
In this example, account IDs starting with w (west) are mapped to the
first JNDI name. Account IDs starting with e (east) are mapped to the second
JNDI name, etc.
- Session enterprise beans can look up WSProxyDataSourceHelper.
from the JNDI namespace (one look up in one enterprise bean lifecycle) in
the setSessionContext method, then call WSProxyDataSourceHelper.resolveDataSourceReference(String) to
get the global JNDI name for every resource reference name.
- During the beginning of the transaction, the session bean calls WSProxyDataSourceHelper.setCurrentDataSourceJndiName(proxyJndiName,
dsJndiName) with the global JNDI name to specify which datasource should
be used. Session enterprise beans can then do normal CMP operations in that
transaction.
- Proxy DataSource uses the Thread Local Storage technique to store the
proxy datasource to delegate datasource mapping. Therefore, only one thread
can be used in one transaction. In a WebSphere EJB programming model, this
means that no remote methods (either CMP, EJBs, or session EJBs) can be used
in one transaction.