Transaction isolation

In relation to IBM® Cúram Social Program Management, the following two fundamental differences exist between traditional IBM WebSphere® Application Server, Oracle WebLogic Server, and WebSphere Application Server Liberty:

  • Traditional WebSphere Application Server and Oracle WebLogic Server enables the creation of multiple thread pools within the same JVM. However, WebSphere Application Server Liberty has a single thread pool, which is named the default executor, that is used to run all application threads.
  • WebSphere Application Server Liberty aligns with the EJB specifications, which declare that EJB remote interfaces use pass-by-value, and that EJB local interfaces use pass-by-reference. While traditional IBM WebSphere Application Server and Oracle WebLogic Server provide an optimization to use pass-by-reference with EJB remote interfaces when the clients of the interfaces are collocated in the same JVM, WebSphere Liberty doesn't provide such an optimization.
The previous differences introduced a risk of thread exhaustion in the runtime application. To mitigate against the risk, the following multi-faceted solution was developed:
  1. Isolate the client HTTP initiated transactions and the JMS initiated transactions.
  2. Introduce EJB session bean local interfaces.

Thread isolation

In traditional IBM WebSphere Application Server, the WebContainer thread pool is set up to process HTTP requests, and the SIBJMSRAThreadPool is set up to process JMS messages. Therefore, the client HTTP initiated transactions and the JMS initiated transactions can be isolated on the same JVM. A similar concept applies to Oracle WebLogic Server. However, HTTP and JMS initiated transactions cannot be isolated inWebSphere Application Server Liberty because it has one single thread pool, which is named the default executor, that runs all application and JMS processing.

To mitigate against the risk of thread exhaustion, the client HTTP initiated transactions and the JMS initiated transactions run on different WebSphere Application Server Liberty instances, integrated through an IBM MQ messaging engine. The Application/EAR file that is responsible for processing client HTTP initiated transactions is called the JMS Producer. The JMS Producer has no JMS message consumption because the EJB message driven beans (MDBs) are disabled. The Application/EAR file that is responsible for processing JMS initiated transactions is called the JMS Consumer. The JMS Consumer has JMS message consumption because the EJB MDBs are enabled. See the following diagram:

Figure 1. Kubernetes cluster with JMS Producer and JMS Consumer replicas
Figure showing a Kubernetes cluster with JMS Producer replicas and JMS Consumer replicas
Note the following important points about the JMS Producer and the JMS Consumer:
Queue manager
IBM Cúram Social Program Management allows only one dedicated queue manager per set of JMS Producer replicas. Also, IBM Cúram Social Program Management allows only one set of JMS Consumer replicas per queue manager. Finally, IBM Cúram Social Program Management allows only one queue manager per IBM Cúram Social Program Management application.
JMS message processing
JMS Producer does not process any JMS message except the cache invalidation messages. The JMS Consumer does not have the IBM Cúram Social Program Management web interface available. After IBM Cúram Social Program Management puts a JMS message on the queue manager, all further processing is handled by the JMS Consumer, which can also put subsequent messages on the queue manager.
Independent scaling
A benefit of the split is that the JMS Producer and the JMS Consumer can scale independently. For example, if a significant increase in backend processing is expected because of eligibility and entitlement calculations, the JMS Consumer can scale up independently of the JMS Producer. After the backend processing is completed, the JMS Consumer can scale down to the normal operational architecture.
Server code split
The solution was facilitated by splitting the server code. For more information about the server code split, see Building EAR files.

EJB local interfaces

When an EJB session bean remote interface is started by using the pass-by-reference optimization in traditional IBM WebSphere Application Server and in Oracle WebLogic Server, the call is made on the same thread. However, WebSphere Application Server Liberty aligns with the EJB specifications, which declare that EJB remote interfaces use pass-by-value and EJB local interfaces use pass-by-reference. As a result, every EJB session bean remote interface invocation results in the use of a new thread from the default executor thread pool.

The existing remote interfaces have been preserved for traditional IBM WebSphere Application Server and Oracle WebLogic Server. An EJB local interface has been added to the following session beans:
  • EJBMethodBean
  • LoginBean
  • AsyncMethodBean
  • SLMTimerBean
  • JDETimerBean

Also, a new JAR file that is named coreinf-ejb-interfaces.jar has been created, which is a consolidation of all the duplicate interface classes in Social Program Management. In WebSphere Application Server Liberty, the coreinf-ejb-interfaces.jar file has been added to a shared resources directory. Therefore, the JAR file is available for each Application/EAR file. In traditional deployments such as traditional IBM WebSphere Application Server and Oracle WebLogic Server, each Application/EAR file has been updated to include the new JAR file within its library path.

For developers, the addition of the new JAR file requires an update to the Eclipse class path, which will be done automatically if the build createClasspaths build target is started as part of a build. For more information, see the Eclipse .classpath file section.

The following classes have been added to the new CuramSDEJ/lib/coreinf-ejb-interfaces.jar file:
  • AsyncMethod.class
  • AsyncMethodLocal.class
  • Authentication.class
  • AuthenticationBase.class
  • AuthenticationLocal.class
  • Method.class
  • MethodImpl.class
  • MethodLocal.class
  • SvrRemoteException.class
  • TimerMethod.class
  • TimerMethodBase.class
  • TimerMethodLocal.class
The following classes have been removed from the CuramSDEJ/lib/jde-commons.jar file, and added to the CuramSDEJ/lib/coreinf-ejb-interfaces.jar file:
  • AsyncMethod.class
  • Authentication.class
  • Method.class
The following classes have been removed from the CuramSDEJ/lib/coreinf.jar file, and added to the CuramSDEJ/lib/coreinf-ejb-interfaces.jar file:
  • Authentication.class
  • Method.class
  • TimerMethod.class