Skip to main content

Batch-like jobs in GlassFish

Please note these forums are being decommissioned and use the new and improved forums at
1 reply [Last post]
Joined: 2003-08-04

I'm looking for inspiration on various approaches to implement batch jobs
on GlassFish

We have a centralized UI and (at the moment) a single ear deployment model
that has served us well so far.

As we implement more and more requirements, a fair amount of them involve
slurping up a bunch of person identifiers and then running various
batch-like jobs over those identifiers. The UI ends up being a glorified
cron/at scheduler, but kicks these off using either @Asynchronous EJBs or
message queues. Think generating thousands of relatively complicated mail
merge documents, that sort of thing. As data sets go, this is a drop in
the ocean, but the processing itself can be relatively intense.

I get queasy thinking about several of these rather intense jobs running on
the same VM against the database. I can think of several approaches to
implementing them differently, but so far the full-on standard Java EE
deployment model has served us so well that I don't want to move away from

Is this a case for clustering the whole app? Or do people spawn new
processes, or...?

I'm aware that JSR 352 is out and I can't wait to take advantage of it, but
even that, as I understand it, would still cause the batch jobs to run on
the same VM; run too many batch jobs and there goes your resources. I'm
sure I must be missing something.

Anyhow, looking for other users-list subscribers' approaches here; any and
all tips are gratefully received.



Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2012-06-01

You can cluster your app and load-balance jobs with JMS. Or you can migrate to JEE 7 and GF4 but I'm not sure how to cluster it as I'm still learning about this batch thing.

With JMS is as easy as creating a Queue resource for a cluster and produce serializable objects (jobs) with enough info to be processed by some MDBs (@MessageDriven).
In this case, take a look at