We know that we can not spawn our own threads from a EJB.
So is it safe to spawn threads from some other class method and then calling that method from the EJB.
We are having a class as
public void process()
childThread ct = new childThread();
class childThread extends Thread
public void run()
//some processing here
Now a SessionBean creates an object of class a(which in turn creates child threads.)
Can we implement threading like it..
Thanx in advance.
No. Hiding thread creation behind another class that your EJB uses is not a way to "get around" the restriction.
There is a reason that thread creation is forbidden and it has to do with the application server being able to control resources (which it can not do if you are creating threads all over the place).
Examine why you feel you need to do things in parallel, and see if you can move the parallelism (at least the dispatching) to your client tier and have the session EJBs do the work.
Your problem might not even be solved by EJBs, so maybe you don't need them...think about that too.
If you really need to run things in parallel inside an application server, you can always use message driven beans. Simply write all your 'work items' to JMS and let the application server handle thread issues (# threads is related to the pool size of the message driven beans). You don't need a special (multithreaded) client application and with some care this approach will even automatically load balance the work items on the different machines of your application server cluster!
The replies above are accurate, you can't spawn threads as per spec, and wrapping the code with another class doesn't help. The "correct" way to solve such a problem is to delegate (using JMS, RMI, whatever). However, in some cases you may want all these threads to run in the same environment (usually for low-level code like finding probable primes). In such cases it can be a major burden to take the code out of the bean. If you decide to use threads inside the bean, use the following guidelines. I don't know of any App server that will have problems with such code:
1. Allways make sure you join() all the spawned threads, or in some other way make sure they are terminated before you return from the call.
2. Don't access resources (JDBC ocnnections, JMS sessions) and don't access container-supplied classes (such as SessionContext). Resources will probably have transaction-related problems, and container-supplied classes can cause deadlocks.
3. Don't synchronize on your bean instance - the container may be synchronizing on it, which will cause you spawned threads to block forever.
This still isn't 100%, but I think it's 99% :)
I keep hearing/reading time and time again that threads for forbidden as per specs though I do not know where in the specs this is explicitly stated.
According to what I read in J2EE 2.0 specs in section 24.1.2 Programming Restrictions :
"An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances"
The above does not mean that threading is forbidden in an EJB code either directly or through another class. It just mean that you are not assume that all instances of EJBs are on the same application server and thus use synchronizations to impose some sort of ordering/sequencing.
Example, I've used the following in my EJBs:
1) Spawn multithreads and then join them later before the call returns
2) Spawn off a thread to perform some time-consuming post-processing just before the call returns
See page 495 in the EJB-2.0 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 enter-prise
bean must not attempt to manage thread groups."
Also, .join() is a thread synchronization primitive, so example (1) violates the spec.