I'd like to know if it's safe to use inside
EJB utility classes that are multi-threaded
(for example an utility class that spawns a
few threads to do I/O on the HD).
Do they conflict with the container Threads?
Waiting for your feedback.....
There's always debate about this.
The spec says your bean can't do it, but it does not say what the classes the bean call can do.
Others argue that the semantics of where you put it are irrelevant, since you are creating threads inside the server you are interfering with it. This is a very compelling argument.
The spec also says you can't use the synchronized keyword but if you use a Hashtable or a Vector anywhere then you are calling synchronized methods. Does it really matter?............
I would say that if the threads you kick off are short lived, and are relatively deterministic (you know they will run for x ms and then will die) then you are relatively OK. However you _must_ make sure your main bean method waits for all threads to complete before returning to the client.
Many people will disagree with the above, but I have never had a problem with it, provided I am only doing simple things. For instance, I need to build an XML document from 5 different data stores and I know 3 of them take a while to run, so I fire them off in parallel and use a barrier pattern to co-ordinate the return to the client. Under very heavy server load I never had a threading issue. (WL 5.1.0)
However, this is not officially supported by the spec so you pay your money and you take your chance...
You absolutely cannot use an EJB to take in a request, fire off a bunch of threads and then return control to the client whilst the threads are still running. If you need to do this then you need an asynchronous technology, like JMS.
Hope that helps.