The other day our tech team in Tarams was discussing the scope of improvement and the possible loopholes in one of the most elaborate Learning Management System(LMS) designed by Tarams Software Technologies which our team designed for one of the largest publishers in the world. It was the regular Friday morning ‘Pause and Think’ meeting where the topic of the day was the performance of this LMS and its enhancement. Since its users run in millions, we gave it a priority to see if its performance would remain equally good with increasing users in near future.
Citing The Problem
The LMS runs in a clustered environment using Oracle WebLogic Server. Running in a clustered environment solves most of our performance problems viz., scalability, reliability and high availability. In spite of this, when we tested our LMS for performance we found that client calls are not being responded as quickly as we expected. After looking into its architecture two questions became dominant: “How to improve its architecture to make the response to web calls quicker?” and “If we have our web requests answered asynchronously?”.
The next day we looked at different solutions available like whether to use Java SDK Thread or JSR 166 (Concurrency Utility for Java) or to use JSR 237 (Work Manager for Application Server) to provide asynchronous strategies to most of the web requests. Going through the documentation of “JSR 237 – Work Manager for Application Server” over Thread and Concurrency Utility for Java, we found Work Manager most advantageous to suit our requirement.
What is Work Manager?
The Work Manager for Application Servers provides a programming model managed by containers (EJB or Servlet) for concurrent execution of work. Work Manager API provides a higher level of abstraction than java.lang.Thread. It uses a single thread pool where all types of work are executed. WebLogic Server prioritizes work based on rules we define and run-time metrics, including the actual time it takes to execute a request and the rate at which requests are entering and leaving the pool. Work Managers are supported by Spring framework and Oracle Weblogic server. This led us to work on JSR 237 and give you an insight into the same.
Using Work Manager
The very first step in using work managers is to configure it in Oracle WebLogic application server. We used Oracle WebLogic Administration Console to configure Work Managers which is one of the many levels of configuration specified in the Oracle Weblogic documentation. BEA Systems and IBM jointly created a specification for Timer and Work Manager API. This API is often referred to as CommonJ. The CommonJ API has Timer API which can be implemented by importing the commonj.timer package and Work Manager API can execute multiple work items within a container, can be implemented by importing the commonj.work package.
Creating Work Manager
Lets see how to create a work manager in Oracle Weblogic Server 10.3.3.0.
Step 1: Login to Oracle Weblogic 10.3.3.0 Console of your environment where you want work manager to be configured.
Step 2: Select Environment -> Work Manager -> Create New -> Give a name “TaramsWorkManager” in this case.
Step 3: Save your work. You will be able to see the work manager created for your target machine at your targeted domain. For security reasons, some of the information here is blanked.
Once we have the work manager configured at Weblogic server, we can use CommonJ API to access this work manager programmatically. We started off with our proof of concept after we came to know that work manager is suitable.Check out Part II of the ‘Improve Learning Management System by WebLogic Work Managers’ for our first proof of concept on work managers.