wood burning stoves 2.0*
The moose likes EJB and other Java EE Technologies and the fly likes Programming restrictions related to threads Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Programming restrictions related to threads" Watch "Programming restrictions related to threads" New topic
Author

Programming restrictions related to threads

Michael Laufer
Greenhorn

Joined: May 30, 2002
Posts: 29
Hi,

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?

Any help (hint) is really appreciated.


Thnaks in advance.

Regards, Michel
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Michael,

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
Michael Laufer
Greenhorn

Joined: May 30, 2002
Posts: 29
Hi Valentin,

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
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Michel,

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:

http://www.onjava.com/pub/a/onjava/2004/03/10/quartz.html

Regards.
 
Don't get me started about those stupid light bulbs.
 
subject: Programming restrictions related to threads
 
Similar Threads
Can i have threads created in EJB Session Bean
Can We Apply User Defined Threads in EJB?
EJB & Multithreading
Doubt abt threads in EJB
Threads in EJB