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