Spawning threads in server process

[kevinstembridge]

Hi folks,
I have a few design questions about creating threads in the main JBoss server process.

I know the J2EE spec prohibits spawning new threads from EJBs but what about from normal business layer classes running in the servlet container? For example, I have seen it recommended that sending emails can be done in a separate thread. But I have also seen arguments against spawning threads in the main server process.

I want to do some time-intensive processing that doesn't require feedback to the user so it would make sense to spawn a new thread. Are there any reasons from a design perspective why this would be a bad idea?

What happens if an uncaught Throwable propagates to the top of the call stack? My understanding is that it will kill the thread it is runnig in but won't kill the main JBoss thread as well.

Thanks in advance.
Kevin

[starksm64]

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

[kevinstembridge]

thanks Scott, I'll check it out.

[rsaraf]

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.

[jimbrady]

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".