A new article on JavaWorld details how to improve the startup time of a Java EE application by converting startup servlets into Work Implementations handled by the WorkManager API. The WorkManager API is an API supported by multiple application servers and designed to allow parallel task execution inside of a managed environment.
The WorkManager API, submitted by BEA and IBM as JSR-237 (which has apparently not gone very far), is supported in Weblogic 9, WebSphere 6, as well as Tangusol's Coherence. It is a simple API allowing you to define pieces of work to be executed in parallel.
A work manager starts a parallel daemon worker thread along with the application server. You configure the work manager through the administration console and give it a Java Naming and Directory Interface (JNDI) name, just as you attach a JNDI name to an EJB component. This JNDI name attached to the work manager is available in the global namespace. When you want your Web module to perform an action, you create an implementation of the Work interface and submit that instance to the work manager. The work manager daemon creates another thread, which invokes the run method of your Work implementation. Hence, using a thread pool the work manager can create threads for as many Work implementations submitted to it. Not only that, the work manager takes a snapshot of the current Java EE context on the thread when the work is submitted.
The article walks through converting an application that has several startup servlets that causes startup time to be on the order of 200minutes. They are able to dramatically improve startup time by allowing the tasks to execute in parallel.
An article on BEA's dev2dev site describes using the WorkManager API in WebLogic Server 9.0 beta. The WorkManager API was also discussed in the comments of an InfoQ post on Grid Computing with the Java Parallel Processing Framework.
Community comments
Does the WorkManager also live in J2EE 1.4?
by Noah Campbell,
Re: Does the WorkManager also live in J2EE 1.4?
by Carey Evans,
Good topic but maybe not the best example
by Martin Perez,
Does the WorkManager also live in J2EE 1.4?
by Noah Campbell,
Your message is awaiting moderation. Thank you for participating in the discussion.
I've seen quite a bit of discussion around WorkManagers lately and they all seem to reference the commonj.* or vendor specific interfaces. Are these different from the javax.ejb.Timer and javax.resource.spi.work.*?
-Noah
www.noahcampbell.info
Re: Does the WorkManager also live in J2EE 1.4?
by Carey Evans,
Your message is awaiting moderation. Thank you for participating in the discussion.
The CommonJ (IBM and BEA) WorkManager and TimerManager APIs are independent of Timer and MDB EJBs, and the J2EE Connector Architecture.
If you get your classloaders all in a row, you could use Timer EJBs instead of the CommonJ TimerManager, and MDBs instead of the CommonJ WorkManager, and run in any application server. If you're writing a resource adapter, you could use java.util.Timer and javax.resource.spi.work.WorkManager.
Good topic but maybe not the best example
by Martin Perez,
Your message is awaiting moderation. Thank you for participating in the discussion.
It's always nice having articles about the commonj spec. I think that is a spec that definitely should be standarized in some way, and in some way someone should boost the actual stale JSR.
But anyways, IMHO probably the article doesn't use the best example at all, and even more I think there is some bad smell in the article. I mean, as the author says, the spec defines loads the webapp servlet sequencially by the defined deployment order. Obviously, the proposed solution is not valid for most cases because it doesn't guarantee the deployment order, but only the startup order.
Probably, the author could easily refactor the solution to have only one unique startup servlet, and then with the work manager he could start the required job tasks for the rest of the servlets.
With this approach, you don't break the deployment order logic.