Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4C480262.4020707@ice-sa.com>
Date: Thu, 22 Jul 2010 10:33:38 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Fire off asynch task in Tomcat.
References: <4C47CFFD.1090603@gmail.com> <4C47F73D.9080707@ice-sa.com>
In-Reply-To: <4C47F73D.9080707@ice-sa.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org