Work has states in its lifecycle, as illustrated in Figure 2
A Work lifecycle starts after the schedule method of Work Manager is invocated. At any given time, Work can be in any one of the following states:
- Accepted: Work Manager has accepted work for further processing.
- Started: Work just started execution on a thread. You can assume this state just prior to entering the run method of Work.
- Completed: Work just completed execution. You can assume this state to be just after exiting from run method.
- Rejected: Work could be rejected at various stages. Work Manager can reject work in case it's unable to process a request.
Work Manager provides a listener interface (WorkListener) that defines four callback methods associated with the Work lifecycle:
Work Manager invokes these methods at corresponding states of the Work lifecycle. The user can implement the WorkListener interface and pass implementation of WorkListener to Work Manager while scheduling work. Work Manager would invoke callback methods corresponding to each state.
Remote Processing of Work
A Work Manager implementation can execute work in a local JVM or transport work for execution by a remote JVM. To process work on a remote JVM implementation, the Work interface needs to implement the java.io.Serializable interface. A Work Manager implementation can check whether Work has implemented the Serializable interface, and then send it to a remote JVM for execution. Processing work in a remote JVM is implementation specific, and some implementations can execute work locally even if Work has implemented Serializable. Work Manager's design encapsulates the complexities of sending work to remote JVMs from a client.
App server providers could implement a scalable Work Manager framework by implementing a work manager capable of executing work on remote JVMs.
Adding Dependency to Work Completion
Work Manager provides a simple mechanism for adding dependencies of work completion on to other tasks. Work Manager provides a simple API for the common join operation. The current specification provides two methods for accomplishing a simple join. Both take a collection of WorkItem objects to check the status of Work objects and a timeout parameter to timeout after a specified interval, even if the condition is not met:
waitForAll(): An application waits for all tasks to complete before moving on to further steps. This is a blocking call with configurable timeout value.
waitForAny(): An application waits for any one of the work items to complete before moving on to the next step.
Work Manager defines two constants that correspond to timeouts:
- WorManager.INDEFINITE: Wait indefinitely for any/all work to complete (Use this option with care, because it could lead your application thread to wait forever.)
- WorManager.IMMEDIATE: Check status of any/all work completion and return immediately