• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Programming restrictions related to threads

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Michael Laufer
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
reply
    Bookmark Topic Watch Topic
  • New Topic