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 BTT 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, BTT 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.