I'm looking for inspiration on various approaches to implement batch jobs
on GlassFish 3.1.2.2.
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
it.
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.
Thanks,
Best,
Laird
--
http://about.me/lairdnelson