Anyway, the basic idea behind that "don't spawn your own threads inside a servlet container" admonishment is based more on the fact that it's quite easy to screw up doing so, more than it has to do with virtually anything else.
You want the servlet container to manager resources for you, and you lose that by spawning your own threads. The container isn't aware of the threads, so it can't control them for things like graceful shutdowns or simply trying to control resource utilization. Many people, including me, tend to ignore that warning when the situation warrants it, but you have to be extra-careful.
For instance, you don't under any circumstances want to hold on to references to response, request or session objects because you don't manage them. You also, unless you really have a need and know what your doing, want to spawn threads to handle requests at all. Any threads you do spawn in a container should tend to be independent units of execution. If your use case fits that description, you can get away with it relatively safely.
That being said, spawning things like daemon threads for low-level behind-the-scenes type processing is generally OK, so long as you are careful (i.e., be sure no runaway processing can occur, make sure it will shut down gracefully, etc). You might be able to use something like that in this case, you'll have to decide. If your using Struts, you can spawn the thread from a plug-in, as I've done in the past, but there are non-Struts equivalents (worse comes to worse, just do it in a servlet.init()). Do yourself a favor and make the thread processing functional independent of your app essentially, and even make it so it's not aware it's running in a servlet container. But again, caution is the key. If you make it a demon thread and set it's priority as low as you can and be sure to not hold on to a reference to it, I've found that works just fine under a number of app servers on a numeber of OSs.
The bottom-line is that really that psuedo-rule is around because people tend to shoot themselves in the foot when using threads a bit too often, so better to advise against getting into a situation where you might do that. But, if your confident in your ability, and believe the use case really warrants it, you CAN do it, and relatively safely.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Dennis Payne wrote:
It is possible to create a servlet thread in the init() method. That thread sould stay alive and run something every thirty minutes. The issue of pushing information out to the user remins the same. The servlet and the thread cannot do that. On the other hand, it is possible to setup java script on the page to detect 30 minute intervals to pull a page from the server.
It is an awful lot of work for so little a result... It is best just to put a java process into cron or task scheduler and have the user run the report when they want the info.
[EMAIL PROTECTED] 12-21-2004 14:44 >>>
Jorge Sopena wrote:
Why is bad using own threads inside web application? Aren't all the servlet request actually a thread in Tomcat? I can't find a reason why it's so bad solution.
I think that comes from J2EE specs. I do not remember is threads just
forbidden but if you follow specs, you do not know and you do not have
to know how application server uses threads and controls thread behaviour. If portability is issue for your application, it is better
to
not use threads.
>
In that way, you manage to have a single and independent
application.
Maybe I don't know some thread behaviour in Tomcat...
After all, I have use threads in web application with tomcat :) and I haven't have any problems or strange thread behaviour. Sometimes whole
concurrent programming and syncronizing my own threads causes troubles
but nothing due tomcat.
Back to original question.
[EMAIL PROTECTED] wrote: I am using Tomcat4.1.30 version. I have to develop a client application which looks in the database
every 30
minutes,
ApplicationContextListener + Timer + TimerTask
to retrieve the status of an order and send the status to the remote
client.
Again waits for the The client's response and insert the repsonse back to the database.
What is that remote client? Is actually another server and your application is client. If so, just add client code for server in TimerTask (http-, web service- or whatever client).
- Jukka -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
