André Warnier wrote:
Eric P wrote:
Hi all,
In my Tomcat app I'm looking for a good (or commonly used) method for
firing off an asynchronous task. For example, a user registers for an
account, and an a task to send a verification email to the user is
triggered w/o delaying the response to the user (i.e., task happens in
the background).
I'm somewhat aware that JMS could be used for this and is part of most
J2E environments, but I'd like to see if there's some way to pull this
off w/vanilla Tomcat.
I had a couple ideas that would probably work, but I'd like to see how
others have solved this problem.
One idea would be to insert a record into a database table that
signifies an email should be sent to the user. This table could be
regularly checked by a scheduled job (e.g., a TimerTask) that runs
every minute in the background.
Another (maybe not so good) idea would be to leverage perhaps a
session or request attribute listener that would check for a certain
attribute being added to a session or requests. Then if a 'send
email' attribute comes through, the listener could process an email.
This seems like a bad idea though as I believe the listener event
class would be triggered incessantly any time attributes are
added/removed when in fact I'm only actually interested in the 'send
email' attribute.
My grain of salt :
It basically depends on how often you expect this to happen (e.g. a new
user registering), and the acceptable delay before the email is sent.
I like very much the first idea (the database record and separate job),
for its simplicity and robustness. It does not depend on any particular
feature or library present in the servlet engine or the Java version, it
does not even depend on the programming language used to write the
email-sending job or the scheduling facilities available on the platform
(think Windows vs Unix/Linux), it makes it easy in the future to change
the email to something else, or add to it, or whatever. It makes it
easy to split these tasks onto separate servers if the need arises
(think that host/user-id which runs Tomcat may not be allowed to send
emails; in most corporate environments, you need a "domain user" for that).
It also makes it possible for the emailing job to collect in one single
loop all recipients which need to receive an email, send them all at
once, and warn the administrator and the sales people that 15 new
customers just signed up.
Talking further to myself, I'll add that it also makes it easier to suspend/resume the
sending of emails separately if you need to for some reason, without having to change
anything to your running webapp.
I know, it is certainly less exciting than using consumer/producer patterns or Executor
classes.. sigh.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
