Its generally fine to use threads as long as you take responsibility for how they interact with the container/ejbs. There are some mbean services that provide thread pools that can simplify basic thread management:

http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigBasicThreadPool

For a Jboss based application I am working on, I want to do a very time consuming task on the EJB side. The task cannot be made faster as it is serial in nature. All I can do to improve the response time is to break the task into smaller pieces. Using JMS queues will be an overkill for the application of that nature. So I was inclined to use threading and wanted to spawn threads from the servlet which will call the service on the EJB side. I want to spawn threads from a request thread and wait for all the threads to return to be able to accumulate the results and send it back in my servlet response.


Can someone suggest a way to do this through threading, also are there any examples or code snippets someone can point.

I have a similar request, and this thread seems to have died. I have started threads from a servlet and it works well (using a global maps and the rule one per user, one per task). My problem is how to manage the security aspect, and Scotts answer really answer that (nice to see there is a pool of threads - but how do you use it)? I have noticed that if the request is terminated the thread keeps running but the security environment has vanished. Ideally, I would like to spawn a servlet as a new independent background request within the same session. Is there a way to do this. Essentially TOMCAT is setting up the environment when a thread is started (Thread pool?) and this environment will change when TOMCAT moves on to something else. If I am just using unsecured reads I don't have a problem, but I am not keen of having database updates labelled "nobody".