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.
- Isolate the client HTTP initiated transactions and the JMS initiated transactions.
- 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:
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 ofJMS 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. TheJMS 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 theJMS Consumer
, which can also put subsequent messages on the queue manager.- Independent scaling
- A benefit of the split is that the
JMS Producer
and theJMS Consumer
can scale independently. For example, if a significant increase in backend processing is expected because of eligibility and entitlement calculations, theJMS Consumer
can scale up independently of theJMS Producer
. After the backend processing is completed, theJMS 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.
- 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.
- AsyncMethod.class
- AsyncMethodLocal.class
- Authentication.class
- AuthenticationBase.class
- AuthenticationLocal.class
- Method.class
- MethodImpl.class
- MethodLocal.class
- SvrRemoteException.class
- TimerMethod.class
- TimerMethodBase.class
- TimerMethodLocal.class
- AsyncMethod.class
- Authentication.class
- Method.class
- Authentication.class
- Method.class
- TimerMethod.class