"[OT]Threads and Servlets Question" on the struts-user list. Jack
On Tue, 21 Dec 2004 18:17:40 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > It's interesting, Craig and I had an exchange about threads in servlet > containers last week... I can't find a link to the thread unfortunately. > > 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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ ----------------------------------------------- "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
