Andrés González wrote:
Maybe a little OT, but: do you think it is a good "architecture" to
have such a background thread processing those records periodically?.
YMMV.
For me I have many jobs running, some timed on a regular schedule, some
timed and/or triggered from events (message passing), some jobs are
setup to be persistable, some are created on demand. But I don't want
to run a full application server. At a cost of a single long running
thread to manage a cron like service.
I mean, wouldn't it be preferable to create a separate process
(another JVM) which would execute that thread?
Maybe if you are only running the job once every 12 hours, if you feel
the cost of eating up a system thread in sleep state for most of the
time is too much. There are still classpath headaches and if you are
doing anything more complex than direct JDBC calls (maybe with an ORM)
just general configuration headaches to deal with by running another JVM
instance.
That way your design is more modular, and you can stop/start that
daemon process easily, without interrupting the Tomcat.
There is nothing to stop you creating a simple servlet to control the
job to enable/disable/kick-start. There is nothing to stop you
persisting that configuration setting.
Infact the above mentioned long running thread to manage things also
takes care of error reporting and logging requirements amongst other
manageability issues that will crop up if you are doing a more complex task.
The only issue with the approach comes when you are running more than
one Tomcat instance (in a cluster) but if you are doing that then the
features of an AS start to look beneficial.
YMMV.
Darryl
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
