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.