Program guide > (deprecated) Partitioning facility > Partitioning facility programming > Proxy DataSource development

Deprecated feature: The partitioning facility (WPF) feature is deprecated. You can configure partitioning with WebSphere eXtreme Scale.

Proxy DataSource programming model

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 eXtreme Scale-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 the 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 eXtreme Scale. 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.

Parent topic:

Partitioning facility programming

Related concepts

Partitioning facility programming

+

Search Tips   |   Advanced Search