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 in still learning
about this batch thing.
On Sep 12, 2013 10:34 PM, "Laird Nelson" <ljnelson_at_gmail.com> wrote:
> 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
>