- Nobody (the spec included) prevents you from creating threads
You just have to follow some rules.

- Besides creating threads I prefer to use servlets/jsp's
that are triggered from the outside to do regular jobs.
(Using cron and wget to trigger the action)
This way you don't have to deal with threads and the job
runs inside the servlet environment.

> -----Original Message-----
> From: d.wall@(protected)]
> Sent: Wednesday, December 31, 2003 1:46 AM
> To: Tomcat Users List
> Subject: Re: Threaded servlets okay in a compliant container?
>
>
> If we use our own connection pools and handle our own transactions
> within the db, is there likely any issue with using other
> threads to do
> background tasks that touch the database? I can see there
> may be issues
> in a regular EJB world with declarative transactions and such
> (does EJB
> have its own "self-thread" type of object that can do
> background tasks
> without waiting for a new transaction event to arrive?), but
> maybe these
> are not a real issue with simpler servlets only.
>
> Background threads are not necessarily compliant, but how would
> anybody effect simple policies like
> "lock out a user's login for 5 minutes after repeated failures," or
> deleting old data in logs, or doing any task every 5 minutes,
> every day,
> once a week, etc.? It seems that everybody who writes a JSP/servlet
> application also has to write standalone Java apps to do
> these things,
> which just complicates matters (another process has to be
> running that's
> not part of the servlet environment so it has to start/stop with it,
> another application has to access the database using yet another
> connection pool, two JVMs means splitting available memory across
> multiple JVMs instead of just configuring the max in one, threads can
> wake each other up for event processing, but this requires RMI or
> another mechanism between two JVMs, etc.)
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)