As some suggested on your blog entry, I think you are may be confusing
EJBs with Servlets as there is a explicit rule preventing you from
creating threads from EJB components but there is none that does the
same with servlets.
The only think is you have to be careful to respect the lifecycle of
your web application, shutting down the threads when your applications
shuts down etc. But apart of that, I've never had a problem spawning
threads from inside servlets, and I do certainly make use of them. We
have, for example, some threads looking for changes in configuration
files, threads inside pools of objetcs etc.
If you want to go for a simple solution, you can go straight for thread
handling etc. For more sophisticated things, you might want to try
something more flexible like Quartz, which we use not only for
scheduling tasks at certain times, but to schedule tasks "right now".
Depending on your requirements, you might want to try to handle the
polling to check if there are new results through AJAX in order not to
refresh the whole page... but on the server side it will work quite
similarly either way (if you use polling, COMET requires other things).
I think some containers also offer you the possibility to use a
container-managed pool of threads that you can use, and they care of the
rest, but that's container dependent, AFAIK, and I've never used it so I
have not opinion there ;).
In short, with plain servlets, no EJB, it's as simple/complicated as you
Daniel Lopez Janariz ([EMAIL PROTECTED])
Centre for Information and Technology
Balearic Islands University
Danny Ayers escribió:
> I would be grateful is someone could answer these questions:
> * Can servlets safely spawn threads?
> * If so, under what conditions?
> I tried to find the answers searching the web, but found conflicting
> views. So I thought it worth asking about a specific servlet container
> I'm trying to make a very simple asynchronous messaging system on top of
> HTTP. What I have in mind requires that the servlet called would
> complete the request-response in "reasonable" time, yet may initiate
> other processes that are potentially long-running. The easiest approach
> would be to have the servlet spawning another thread in which to run the
> other process, and return a response to the client immediately. But is
> this possible without running straight into concurrency breakage?
> More background at :
resin-interest mailing list