Runtime components : Core components : CHA : CHA programming model : Local context
  
Local context
The context in local mode can be an anonymous or pre-defined Context created by the application as a part of its business processing. Contexts of this nature are used as temporary storage collections that may be passed as a unite to other logic within the same application. These contexts are not shared outside of the VM in which the application runs, except as a part of a serialized object stream. In this regard, they are the same with any other local serializable object. There is one way to change the mode of a context from local to remote with the API of setRemote().
The local Context has many advantages over the distributed (Client/Server) Context:
Higher performance with no networking or EJB-included latencies.
Simpler operation with no EJB framework interaction. All operation code is contained within the application.
Smaller system-wide memory usage. The single self-contained component has no client and server code and data to manage.
Least impact on client code which uses direct access to Data Element values as a means to update Context content, because the Context is local to the application, operations that depended on this fact can operate without any change.
Local contexts are serializable and may be shared using messaging techniques such as RMI serialization or serializable parameter. However, messages of this type or parameter can became large depending on the content of the local-mode Context.
The disadvantages of the local context are:
Data cannot be shared within the Context hierarchy.
Local Contexts may not take part in a Context hierarchy except as leaf nodes. While you can chain a local-mode Context to a remote-mode Context, you cannot chain a remote-mode Context to a local mode Context.
Local-mode contexts may not be constructed from definitions in the DSE xml files. These are dynamically created and are anonymous.
Local Context cannot be persistent by CHA server. Thus the fail-over support cannot be leveraged on CHA server itself.
Note One possible way to support fail-over is to persist Local Context into HttpSession managed by WebSphere.
Go up to
CHA programming model