In Local mode CHA implementation, all context operations and instance allocations are based on local memory. It has no EJB and persistence support. The context instance is kept in Facade side. There is no need for persistence support. When you choose Pure Local mode CHA implementation, you do not need EJB related code and environment.
▪ Persistence shared CHA: Remote CHA with EJB and persistence support.
▪ Memory shared CHA: Remote CHA with only EJB support.
Persistence shared CHA
Persistence shared means Remote CHA with EJB and persistence support.
Persistence shared CHA architecture
The following diagram shows a high level view of the Persistence shared CHA architecture:
A service or business process instantiates a local or remote CHA context using the API of the Context class. Note that the service or business process can use a provided name or a generated one. The service or business process interacts with local and remote contexts using the same API.
The client side of a remote context is little more than a mechanism for passing requests on to the server side. It delegates business functions to the server side.
In the CHA server, EJB instances create and maintain the server side of remote contexts. A session bean (CHASession) handles static method calls while an entity bean (CHAInstance) handles instance method calls. Note that the Context class does not require access to the CHAInstance home interface to retrieve a remote interface. The CHASession EJB can perform all instance queries using local EJB interfaces to create or find CHAInstance objects.
The client side of the context or a non-toolkit J2EE client drives the creation of the EJBs. Toolkit applications cannot directly create the EJBs. Each context has an instance ID, which is unique in the global system. Note that the server side of a remote context identifies whether the context is static or dynamic depending on whether the definition files contain a definition for the context. See Context type for more information.
▪ In EJB container, a singleton is used to access hashMap which contains the whole remote context tree.
▪ CHA facade access CHA server via CHASession session EJB. CHA facade does not interact with CHAInstance EJB directly.
▪ Load the contexts which are always session context and its children from DB into memory when a HTTP request begins if those contexts are needed for processing the HTTP request. Save the contexts from memory into DB if those contexts are changed when the HTTP request ends. When a user logoff, the session context and its children will be removed from DB.
The remote CHA context is stored as a cache in memory, which greatly improves the performance of CHA remote context. A singleton is used to access hashMap which contains the whole remote context tree.
You can use one hashMap to store the information related to the context.
The key of the hashMap is an instance ID and the value is context object. CHA will manipulate this hashtable using instance ID as the key. For example, you can insert, delete or update the context according to the instance ID.
The children-parent relationship is stored in each context instance. Variables in the context for this purpose are as follows:
▪ ParentInstanceID: indicates the parent's ID. If there is no parent, the value is null.
▪ ChildInstanceID: a vector holds the IDs of its children.
The following is the possible deployment picture in a production environment for UDTT CHA. In the deployment, CHA must be packaged together with other components such as struts, Single Action EJB,etc.
The execution sequence described below can help you understand the architecture.
▪ When a user logon, the user may execute several web pages to accomplish an internet bank transaction. For each web page, the client (for example, a browser) will send a HTTP request to server (for example, a cluster) in the figure above. These HTTP requests are sent out sequentially and each of them may be executed on different node in the cluster.
▪ Suppose Node1 receives HTTP request 1, HTTP request 1 can only be processed in Node1 when using "Local Prefer" selection policy which is a default policy. To process this request, Node1 may create, or update, or read a context which is probably a session context or one of its children.
▪ If the node creates a context, it creates the context into memory context tree but not into the DB.
▪ If the node reads a context, it reads the context in the memory context tree. If it can not find the context in memory context tree, then it reads the context from DB and put it into memory context tree.
▪ If the node updates a context, it read the context at first using the read approach above, then it updates the context in memory but not in DB.
▪ During the subsequent process for the HTTP request 1, there may be a lot of manipulations for the its session context and its children such as formatting/unformatting a context, executing setValueAt() or getValueAt() on a context, etc. All these manipulations are done in memory.
▪ When HTTP request 1 ends on Node1, UDTT frame work will automatically execute commit() API on its session context. This API will commit the change during this HTTP request for session context and all of its children which have dirty data into DB and it will delete session context and its children from memory context. To commit only contexts with dirty data into DB is aimed to reduce the access of DB and improve the performance. In this way, the memory usage is reduced.
▪ When a user logoff, the session context and its children are deleted from DB.
CHAInstance entity EJB
CHAInstance is a CMP entity EJB that wraps the server side of a remote CHA context. CHAInstance manages the creation, persistence and linking of the context to its parent in the hierarchy.
CHAInstance provides an API that enables an application to do the following:
▪ Adding a value to the CHAInstance
▪ Querying one or more values from the CHAInstance
▪ Removing values from the CHAInstance
CHASession session EJB
CHASession is a stateless session EJB that provides the necessary access functionality to work with CHAInstance EJBs and singleton without the need of the client code accessing the CHA Instance Home interface. To do this, all access at this level is performed on behalf of the client by using the CHASession session bean. The front-end component of the CHA server is the CHASession stateless session EJB. It is the sole entry of CHA server. It provides finders and creation methods for creating and querying for CHA instance entity beans. It also provides the method to call the singleton to access the context tree in memory.
CHASession provides the following functionality:
▪ Creating/Removing/Searching for CHAInstances
▪ Creating/Removing/Searching for context from singleton
All of these methods will access a local version of the CHAInstance home interface since the CHA Instance EJB instances will be in the same EJB container as the CHA Session EJB. The use of the local EJB Home interface enhances performance by reducing the need to consult JNDI or remote semantics for CHA Instance retrieval and manipulation.
Support for non-toolkit applications
A non-toolkit application can use the CHA EJBs as a way of storing runtime data in a remote environment.
The application accesses the CHASession session bean to create a CHAInstance bean to store the data. The CHAInstance can be anonymous or named depending on whether the application supplies an identifier. Anonymous CHAInstances have a generated unique ID that the application can obtain from the session bean. The application can then use this ID to manipulate the CHAInstance. If the application names the CHAInstance, the name must be unique across the entire system. An option exists for a CHAInstance factory to add values to the application supplied name to ensure the name is unique. Once the CHASession has created the CHAInstance, the application can then use the CHAInstance API.
The CHA EJBs provide both local and remote interfaces. CHA clients, like Struts or SAE, can access CHA server via local and remote interface.
How the Persistence shared CHA works
Applications use static methods to manipulate context data on the server side. The static methods are factories that return a Context instance to the caller.
To create a remote context, the following happens:
▪ CHA client use "new context(...)" API of context class to invoke the creating process.
▪ When CHASession EJB in the server side receives the creating request, it calls the CHAMetaData to read the external definition of the server side context.
▪ The CHASession uses the definition to create the context with unique instance ID.
▪ The created context object will be inserted in to the HashMap of the server side memory for caching.
▪ The CHASession receives the instance ID of the newly created context and passes it back to the client side context.
The following sequence diagram shows this process:
To modify a value of a data element by calling setValueAt():
The setValueAt() only modifies the content in memory. The modification can be committed into database when the http request finished and execute commit(). In CHA server side, before modifying a context, you need find it first. The context could be in memory or in DB. So there are two sequence diagrams here to illustrate the two cases.
If the context for the data element has already in memory, the following happens:
▪ The client side use setValueAt() API of context class to invoke the set-value process.
▪ When CHASession EJB receives the request, it firstly invoke getContext() API to find the context.
▪ The context will be searched in the HashMap with its instance ID.
▪ The found context object is returned to CHASession.
▪ CHASession calls setValueAt() API of the returned context object to perform the set-value task, and then returns.
The following sequence diagram shows this process:
If the context for the data element does not exist in memory, the following happens:
▪ The client side use setValueAt() API of context class to invoke the set-value process.
▪ When CHASession EJB receives the request, it firstly invoke getContext() API to find the context.
▪ Then, the CHAInstance EJB is created and a SQL query is executed in the database by CHAInstance to search the context.
▪ The found context object is returned to CHASession.
▪ CHASession update this context object into HashMap in the server side memory for caching.
▪ After the update, CHASession calls setValueAt() API of the context object to perform the set-value task, and then it returns.
Commit the session context and its children into DB:
If the context for the data element does not exist in memory, the following happens:
▪ BTTRequestProcessor receives and processes the HTTP request.
▪ BTTRequestProcessor gets the session context instance ID from CSSessionHandler, and gets session context from CHASession EJB using this instance ID.
▪ BTTRequestProcessor calls sessionCtx.commit() API to perform the commit task.
▪ When CHASession EJB receives the commit request, it gets the session context and all the children at any level.
▪ CHASession EJB calls CHAInstance APIs to create or update the session context and all of its children contexts at any level which have dirty data into database.
▪ The session context and all its children context at any level are removed from the memory cache, and then it returns.
Memory shared CHA
Memory shared means Remote CHA with only EJB support.
The memory shared CHA is a sub-set of the whole CHA architecture. In the memory shared CHA, CHAInstance CMP bean and the database are excluded from the CHA architecture. The context persistence feature is not used.
To the local contexts, there is no difference between memory shared CHA and persistence shared CHA. But for remote contexts, there are differences: remote contexts under the memory shared CHA always stay in the singleton memory cache during their lifecycles, and they will never be stored into the database.
Access to the database is very time-consuming and always impacts the performance of a UDTT application. Therefore, to remove the database dependency and to keep all the runtime data in memory can guarantee good performance of the UDTT applications, especially CHA performance.
Memory shared CHA has one limitation: it does not support fail-over because session and root level data cannot be persisted into database under the cluster environment. However, there are several ways for the UDTT application to bypass this limitation:
▪ Keep the data of session and root level contexts read only. Zero modification of the data from such contexts will guarantee that there is no difference of each single application instance from the cluster.
▪ Keep the session and root level data in consistency under cluster environment in the application's scope.
▪ Store the difference of session and root level data in different application instances. When one application fails, the other can quickly restore from the stored difference.
To leverage the memory shared CHA, you need to identify only one item: to fill "startMode" with "MemoryShared". There is no need to create JDBC provider and data source in WebSphere Application Server for CHA:
Furthermore, the function of "cleanupCHAServer" is disabled under memory shared CHA.
CHA server initialization
You can use startup beans to initialize CHA server that runs on either Rational Application Developer or WebSphere Integration Developer.
See CHA startup beans for details about initializing the CHA server with the startup beans.
In the btt.xml file, the initTailContextName setting identifies the leaf context in the initial context tree. The initial context tree is always linear in structure. The definition for the context is in the context definition file as show in the following example:
In this example, the branchServer context is chained to the sessionCtx and both are in the database after the CHA server starts.
Deployment topologies
The CHA has a wide range of deployment options to support small enterprises using a single server to large enterprises with multiple CHA servers. The following topics describe some of the possible deployments achieved simply by changing the way you configure the CHA server and your applications.
Single CHA server with co-resident clients
In this topology, the single CHA server and the CHA clients reside in the same EJB container. The clients use local EJB bindings to access the CHA as shown in the following figure.
This topology provides the best performance because all of the EJB interfaces are local except for the external call to the business process EJB component.
Single CHA server with remote clients
In this topology, the single CHA server and the CHA clients reside in different EJB containers. This topology uses IIOP/RMI technologies to provide true remote CHA support to the application. All communication between the client and server is remote.
This topology requires extra processing because RMI reduces performance.
