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 (<flamebait>and 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]
