tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Fire off asynch task in Tomcat.
Date Thu, 22 Jul 2010 07:46:05 GMT
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.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message