Re: Architecture ideas for batch processing?
- From: Bjorn Borud <borud-news@xxxxxxxx>
- Date: 13 Jun 2005 02:19:00 +0200
["Alan Meyer" <ameyer2@xxxxxxxxx>]
|
| But it means that if one job crashes it can bring the others down
| with it. It also means that if one job goes into a loop and has to
| be terminated, the operator will have no choice but to kill
| everything.
what do you mean by "crash" here? threads dying because of unhandled
exceptions or hard errors that make the JVM die?
I'd prefer to model the batch processing APIs so that you don't really
have to make a decision before you know you have to. you just
abstract away if the job runs in the same JVM or not. provide
implementations for running jobs in the same JVM first. if it becomes
a problem doing so or it would make sense for other reasons to move
the processing elsewhere, implement whatever is needed for sending the
batch job to a different JVM (possibly on a different machine).
the important part is to
- have proper abstractions so that later you have the freedom
to choose.
- implement the remote processing when needed, and not start by
prematurely assuming that it is required.
good luck!
-Bjørn
.
- Follow-Ups:
- Re: Architecture ideas for batch processing?
- From: Chris Uppal
- Re: Architecture ideas for batch processing?
- References:
- Architecture ideas for batch processing?
- From: Alan Meyer
- Architecture ideas for batch processing?
- Prev by Date: Re: Architecture ideas for batch processing?
- Next by Date: Re: Shortage of qualified Java programmers
- Previous by thread: Re: Architecture ideas for batch processing?
- Next by thread: Re: Architecture ideas for batch processing?
- Index(es):