Runtime tools : Channels components : Session context failover : Java Serialization / Deserialization : Feature Enhancement
  
Feature Enhancement
In this release, UDTT 10.4 has made enhancement changes to the session context failover feature.
The first change is to set the default value of serializeParentsAndChildren to true to support all levels of context parents to be serialized, and the application is not required to call the API to set the property one by one for a specific context.
The second change is to add the support of UDTT Service serialization in the context reference. UDTT has added a new property "Serializable=true/false" for service reference in the context definition.
The property will be used to determine whether to serialize the service in the context reference. The default value is false, so if there is no property defined, the service is not serialized.
It will help to improve the performance to avoid unnecessary serialization and help to remove the error message when the service class contains un-serializable fields.
The following is a service definition example with serializable property in service.xml.
<context id="branchServer" parent="nil" type="branch">
<refKCollrefId="branchData"/>
<refServicealias="mockedMQService" refId="mockedMQService1" type="host" serializable="true" />
<refService alias="realCSServer" refId="realCSServer" type="cs" />
</context>
The transaction editor for context is shown in following diagram:
This graphic is described in the surrounding text.
Note For UDTT in-house implemented services, like MQ Service or Database services, the serialization is not implemented. This is due to the UDTT in-house services being local connection services which depend on the local environment, which cannot be shared. If a user has the requirement of sharing the custom services in cache, that user can benefit from implementing the serialization interfaces.
The following is a use case example of how the UDTT application failover behaves. For example, there are two Liberty Servers A and B. And there is a load balance frontend like HTTPD. Now there are 3 users who established 3 sessions. Session-1 and 2 are on Server A and Session-3 is on server B. In server A, UDTT session context 1 and 2 are chained to branch context A which is created when UDTT server is initialized. In Server B, UDTT session context 3 is chained to branch context B. When server B is down for some reason, the flow user session 3 will continued to be handled by Server A. The framework will restore from the cache the session context 3 and branch context B and the flow context as well. The user is not aware of the failover.
Go up to
Session context failover