|
|
If you can't handle long task, then break it into pieces
Eugene Kuleshov's Blog |
January 23, 2006 8:20 AM
|
Comments (2)
Billy Newport blogged about dealing with long running synchronous operations. Most of the post he was mussing about increasing timeouts for long running EJB calls on client on server side. That helps in some cases, but does not solve root of the problem and don't really scale for a heavy load. Then Billy suggest to use JMS for async processing and if client can't wait for JMS responses let him to pull process information. Obvious, but not much details.
It would make sense to split long-running process into smaller tasks upon activation (e.g. post a JMS message for every subtask), execute each task in a separate transaction (e.g. using MDBs), and then assemble results and send notification to the client using JMS or client callback (e.g. EJB or RMI call).
Because subtasks can be processed in parallel, and even run across multiple nodes, the above approach will scale very well. However initial subtask creation may take significant time and still run into the transaction timeout. In this case it would make sense to limit number of subtasks and post special trailer message that will create another batch of subtasks for processing. If no subtasks available the same trailer message can kick a result assembler (e.g. again implemented as an MDB) which will also run asyncronously and notify client about task completion.
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
JSR 236/237 (supported by IBM WebSphere which Billy works on, BEA WebLogic, and Tangosol Coherence) supports the invocation of a whole slew of async items (called "work"), it supports an option to wait for their completion, and supports an optional timeout on that wait. Tangosol's implementation is already clustered (allowing distribution within a cluster), and while both IBM and BEA ship a version that is not clustered, both apparently already have clustered versions written and tested (just not released yet).
The JSR 237 WorkManager is being proposed as the standard way that J2EE tasks utilize multiple threads in parallel, either on a single server or in a cluster.
Peace,
Cameron Purdy
Tangosol, Inc.
Posted by: cpurdy@tangosol.com on January 23, 2006 at 6:20 PM
-
Cameron,
Sometimes developers need this in J2EE 1.3 containers and what Eugene was trying to say I guess, is that it's totaly doable with just plain MDBs and little imagination ;-)
Btw MDB approach could be easily wrapped into WorkManager interfaces as demonstrated here https://xcommonj-work.projects.dev2dev.bea.com/ so they could start with plain vanilla J2EE server and than migrate to new version later.
Moreover, JSR 236 is not part of J2EE spec while MDB are, which could matter for some companies as well.
Posted by: maximdim on January 23, 2006 at 7:06 PM
|
|
