RE: Why not to create threads?
Howdy, Why should I be avoiding creating my own threads in a web application? I have a couple of scheduled components, and I'm not sure how else I would implement them. It's OK to create and use threads as long as you're careful for synchronization issues. Threads are a powerful construct when used by able developers but can cause very difficult problems to diagnose/debug if not used carefully. You should probably not write threading utilities from scratch. Instead, use something like Doug Lea's concurrent library, http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/int ro.html, which will be part of the JDK 1.5 release. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why not to create threads?
Because the appliction server does this for you. If you interfere by using your own threads you could break stuff... (it's a spec violation too). Also you should use an application server for scheduling components. (We use JBoss MXBeans for this purpose). Regards, Harm de Laat Informatiefabriek The Netherlands Walker Chris [EMAIL PROTECTED] 10/28/2003 05:05 PM Please respond to Tomcat Users List [EMAIL PROTECTED] To 'Tomcat Users List' [EMAIL PROTECTED] cc Subject Why not to create threads? Why should I be avoiding creating my own threads in a web application? I have a couple of scheduled components, and I'm not sure how else I would implement them. Chris -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 15:53 To: Tomcat Users List Subject: Re: Number of processes and relationship to mod_jk, Apache, tomcat snip If you avoid creating your own threads in your web application (which you should be avoiding anyway), you're generally okay. /snip The information in this e:mail and any attachments or any reproduction of this e:mail in whatever manner is confidential and for the use of the addressee(s) only. If you are not the addressee then the distribution, use or reproduction of this e:mail or the information within it is strictly prohibited and may be unlawful. If received in error please advise the sender and delete all record of it from your system. Although believed to be virus free, accurate and complete, responsibility for any loss or cost arising from its receipt or use or its incomplete or inaccurate transmission is hereby excluded to the fullest extent possible. - 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]
Re: Why not to create threads?
Chris, Why should I be avoiding creating my own threads in a web application? I have a couple of scheduled components, and I'm not sure how else I would implement them. I realize ther sometimes it's just necessary, so I'm not trying to tell you that you're wrong for creating threads. That being said... First, HTTP is a connectionless protocol. We've only invented the concept of the session to get around this feature. All transactions should take place within the request-response model. That doesn't work for all web sites, so we use sessions. Fine. Second, managing your own threads within a servlet-type of environment is tough. You have to make sure that you don't create too many threads, or that they don't take up too much processing time, that you don't lose track of them, etc. You appear to have a very domesticated daemon thread that's almost unrelated to responding to requests, no? Third, the J2EE EJB specification for Enterprise JavaBeans specifically forbids it. You aren't supposed to be creating your own threads because you're not suppsosed to know where your code is running. Sure, on one machine, it's running right there, in the same VM you thought it was going to start in. However, in a clustered environment, your code may be running on a completely different server. There's actually a lot of fascism when it comes to the EJB spec. Among other things, you're not supposed to do any of the following: - Create your own threads - Instantiate any of the classes in the java.io package directly Now, I know that not everyone is running an EJB container, and that J2EE is a ton of specifications and services, of which EJB is only one (flamebaitand a poor one at that :)/flamebait). But the fact that many servlet-based applications end up going the way of the EJB, you might want to play by their rules if you can. Note also that if you have a Servlet container that merely connects to an EJB container then you are not bound to these restrictions. However, many EJB containers also act as servlet containers, and they may impose these restrictions across the board. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why not to create threads?
Howdy, The rest of the message aside, I had an only partially related question: (flamebaitand a poor one at that :)/flamebait). But the fact that many servlet-based applications end up going the way of the EJB, you might want to play by their rules if you can. Can you quote research that shows a large percentage of servlet-based applications are eventually migrated to be EJB applications? Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why not to create threads?
You are allowed to create your own threads. But there are restrictions and limitations for user created threads such as ... - They should not touch Request and Response objects - The should be able to know when the servlet container stops if non-daemon so the jvm may gracefully terminate - If daemon - have a quick shutdown(or appropriate) since the container may shutdown the moment all threads are done with their service() method (I probably got this wrong, but the spec describes this better) - High perfomance containers are allowed to restrict thread creation - All of the fun concurrency issues -Tim [EMAIL PROTECTED] wrote: Because the appliction server does this for you. If you interfere by using your own threads you could break stuff... (it's a spec violation too). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why not to create threads? (OT)
Yoav, The rest of the message aside, I had an only partially related question: (flamebaitand a poor one at that :)/flamebait). But the fact that many servlet-based applications end up going the way of the EJB, you might want to play by their rules if you can. Can you quote research that shows a large percentage of servlet-based applications are eventually migrated to be EJB applications? I only said many, not a large percentage. I'm sure there's been more than one :) Honestly, I'm not willing to conduct such a study and I was shooting my mouth off. Sometimes, servlet-based apps move to EJB containers. If that's your case, you might want to avoid creating your own threads. To be safe no matter what, I avoid creating new ones at many (not all) costs. There's more than one way to do it (don't tell any of the Perl peeps out there that I'm stealing their line). -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
