21.4.4 Developing applications by using WorkManager
This section describes development of applications by using WorkManager.
The following table describes the usage status of components, which configure an application, when using WorkManager.
|
Component |
Usage status |
|||
|---|---|---|---|---|
|
EJB client |
N |
|||
|
Resource adapter |
N |
|||
|
JavaBeans resources |
N |
|||
|
Servlet/JSP# |
Y |
|||
|
EJB |
Stateless Session Bean |
EJB2.1 or earlier versions |
CMT |
Y |
|
BMT |
Y |
|||
|
EJB3.0 |
N |
|||
|
Stateful Session Bean |
N |
|||
|
Entity Bean |
N |
|||
|
Message-driven Bean |
N |
|||
- Legend:
-
Y: Can be used
N: Cannot be used
- #
-
You can use the components also for the servlet listener or the filter.
The procedure for developing an application by using WorkManager is as follows:
-
Defining the properties of EJBs or servlets, which are the schedule sources
-
Implementing the processes to be executed in Work and Listener
-
Creating EJBs or servlets, which are the schedule sources
-
Compiling J2EE applications which uses WorkManager
Details of each task are as follows.
- Organization of this subsection
(1) Defining the properties of EJBs or servlets, which are the schedule sources
Define EJB or servlet properties, which use WorkManager, in the DD. Define the properties in property definition file of EJBs or servlets. You cannot define the properties in an annotation.
The following table describes the properties, which you must define to use WorkManager.
|
Tag name |
Explanation |
|
|---|---|---|
|
<Root-tag> |
-- |
|
|
<description> |
Set optionally. |
|
|
<res-ref-name> |
Specify the JNDI ENC name (name to be used for JNDI lookup). |
|
|
<res-type> |
Set the following value. commonj.work.WorkManager |
|
|
<res-auth> |
The set value is ignored. |
|
|
<res-sharing-scope> |
Set Shareable. However, even if you set Unshareable, the same operation as for Shareable is executed (WorkManager is created when application starts and the same WorkManager is returned when lookup is performed). |
|
|
<mapped-name> |
The set value is ignored. |
|
|
<injection-target> |
The set value is ignored. |
|
|
<linked-to> |
The set value is ignored. |
|
The definition example of web.xml when you use WorkManager in the servlet is as follows:
<web-app>
<display-name>WorkManagerSample</display-name>
<servlet>
<servlet-name>SampleServlet</servlet-name>
<display-name>SampleServlet</display-name>
<servlet-class>SampleServlet</servlet-class>
</servlet>
<resource-ref>
<res-ref-name>wm/MyWorkManager</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</web-app>WorkManager is automatically created depending on property definitions when you start the application. The number of WorkManager, defined in the property, is created.
(2) Implementing the processes to be executed in Work and Listener
To use WorkManager, you must create Work and the listener, with which the processing to be executed is implemented. There are two types of interfaces - Work interface having the run method, which is a process entity, and WorkListener interface used to execute the process at the times such as process reception, start and end. Among these interfaces, make sure to implement Work. For details on APIs, see the API specifications in Timer and Work Manager for Application Servers.
The following figure shows the procedure which is invoked by API of the WorkListener interface and the status transition.
|
|
The WorkListener method and the Work.run method are invoked in the same thread. As a result, you can use the common Java EE context for each method.
The following section describes the flow and implementation example of the processes executed in the daemon Work and the non-daemon Work, and also the implementation example of WorkListener.
- The flow and implementation example of the processes executed in the daemon Work
-
To use the daemon Work, implement Work in such a way that the isDaemon method returns true.
When WorkManager ends, the container executes the release method to stop the daemon Work. Therefore, implement in such a way that process of the run method ends when the release method is executed. Note that if the method is not implemented properly, the daemon Work might not stop when you stop WorkManager and continues to wait endlessly.
The implementation example of the daemon Work is as follows:
public class MyWork implements Work { private String name; private boolean isLoopContinue = true; public MyWork() {} public void release() { isLoopContinue = false; } public boolean isDaemon() { return true; } public void run() { while (isLoopContinue) { System.out.println("DaemonWork is executed"); try { Thread.sleep(10000); } catch(InterruptedException e) {} } } public String toString() { return name; } } - The flow and the implementation example of processes executed in the non-daemon Work
-
To use the non-daemon Work, implement Work in such a way that the isDaemon method returns false.
The processes of non-daemon Work must end during scheduled processes of EJBs or servlets. Therefore, implement the process in such a way that the EJB or servlet process ends after waiting for the scheduled work to end. To wait for the end of the scheduled Work, use the waitForAll or waitForAny method. If the process of EJBs or servlets ends before the end of the scheduled Work, the Work process is executed beyond the life cycle of the scheduled EJB or servlet. Make sure to end the process in a user program by using methods such as the waitForAll method, so that the non-daemon Work is not executed beyond the life cycle of the scheduled request.
The implementation example of the non-daemon Work is as follows:
public class MyWork implements Work { private String name; private String data; public MyWork(String name) { this.name = name; } public void release() {} public boolean isDaemon() { return false; } public void run() { data = "Hello, World. name=" + name; } public String getData() { return data; } public String toString() { return name; } } - The implementation example of WorkListener
-
The implementation example of WorkListener is as follows:
public class ExampleListener implements WorkListener { public void workAccepted(WorkEvent we) { System.out.println("Work Accepted"); } public void workRejected(WorkEvent we) { System.out.println("Work Rejected"); } public void workStarted(WorkEvent we) { System.out.println("Work Started"); } public void workCompleted(WorkEvent we) { System.out.println("Work Completed"); } }
(3) Creating EJBs or servlets, which are the schedule sources
To use WorkManager, implement lookup of the JNDI name of WorkManager, which is defined in properties, and the process scheduling of WorkManager, in EJBs or servlets, which are the schedule sources.
- The JNDI name of WorkManager defined in properties
-
Perform lookup for the JNDI name of WorkManager, which is defined in properties, to acquire WorkManager. Use java:comp/env for lookup. The example of acquiring WorkManager is as follows.
InitialContext ic = new InitialContext(); WorkManager tm = (WorkManager)ic.lookup ("java:comp/env/wm/MyWorkManager"); - Scheduling the WorkManager process
-
Execute the scheduling of the WorkManager process by invoking the schedule method of WorkManager.
An example of a program which waits for of all Work to end, after scheduling multiple non-daemon Work is as follows.
MyWork work1 = new MyWork(); MyWork work2 = new MyWork(); InitialContext ctx = new InitialContext(); WorkManager mgr = (WorkManager) ctx.lookup("java:comp/env/wm/MyWorkManager"); WorkItem wi1 = mgr.schedule(work1, new ExampleListener()); WorkItem wi2 = mgr.schedule(work2); Collection coll = new ArrayList(); coll.add(wi1); coll.add(wi2); mgr.waitForAll(coll, WorkManager.INDEFINITE); System.out.println("work1 data: " + work1.getData()); System.out.println("work2 data: " + work2.getData());
(4) Compiling the J2EE application, which uses WorkManager
Include the following JAR file when you compile the J2EE application, which uses WorkManager.
Cosminexus-installation-directory\CC\lib\ejbserver.jar