I know that "onw" thread management is restricted for good reason in the EJB specification (EJB 2.1, 25.1.2):
----------extract from spec.--------- The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread�s priority or name. The enterprise bean must not attempt to manage thread groups. These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads would decrease the container�s ability to properly manage the runtime environment. ----------end extract from spec.---------
Now comes my qustions, I don't find a similar part in the servlet specification. Am I missing something, or to be more detailed, is it allowed to create an own thread there? E.g. for scheduling purposes? Are there any particular risks or disadvantages of creating such a thread in a servlet?
Now comes my qustions, I don't find a similar part in the servlet specification. Am I missing something, or to be more detailed, is it allowed to create an own thread there?
The major difference between EJBs and servlets, from a multithreading perspective is that for EJBs there is always one active bean instance for each running client transaction. This instance is single threaded and this is why the bean itself should not attempt to manage threads, because it will mostly break the container�s thread management. Is important to notice also that for performance and optimization reasons the container maintains a free pool of beans. Servlets on the other hand have none of these limitations and they really don�t care about any concurrency or thread management. The web server won�t bother much about that either. In fact unlike EJBs, only one servlet instance can service any number of concurrent users and developer should take care about synchronizing instance variables (again no help from the web server here � big difference though!). Usually containers don�t pool them, unless some special circumstances demand it. Weblogic for example will maintain a pool of servlet instances if the corresponding servlet implements the SingleThreadedModel. And this not because of any intend of managing threads. It�s only for improving the performances. In theory at least, starting a new thread in a servlet instance should probably do no harm. In practice though this should be discouraged since the side effects could be disastrous. And this not only because the thread synchronization could be difficult to implement, but the resulting code would be also difficult to debug and maintain. Another reason why I wouldn�t recomand such practice is because the container itself maintains a pool of execution threads. Having an uncontrolled servlet that reserves threads arbitrary will mostly degrade overall server performances.
E.g. for scheduling purposes?
If it�s only for that, why not to use a third party software? Quartz might be a good candidate for your needs. However if you want to have your own scheduler, rather than starting a new thread within a servlet, you better have a servlet that manages the scheduling and set the load-on-startup descriptor. Regards.
I think, therefore I exist -- Rene Descartes
Joined: May 30, 2002
thanks for the great and extensive response to my question. Unfortunately Quartz is no option in our project, so that I really have to implement my own scheduling logic. This brings me to your last point
<quote> However if you want to have your own scheduler, rather than starting a new thread within a servlet, you better have a servlet that manages the scheduling and set the load-on-startup descriptor. </quote>
I could image starting a servlet with the load-on-startup descriptor, but how should I schedule regular, i.e. time-dependent actions, without creating an own thread within the corresponding servlet that takes over the scheduling responsibility? Do you have any idea? I have to create a thread from my point of view, or?
I really appreciate your support.
Kind regards, Michel
Joined: Feb 17, 2005
If I give it a second thought I'd probably step back and say that for scheduling jobs you don't need a web server and any running servlet code. Having a simple java application that does the job and writing/scheduling a shell script that invokes your java code should probably be quite enough. Besides Java contains the Timer and TimerTask classes that can be used for this purpose. Ultimately you can read this article and see if it can help you: