The container must ensure that only one thread can be executing a stateless or stateful session bean instance at any time. Therefore, stateful and stateless session beans do not have to be coded as reentrant. One implication of this rule is that an application cannot make loopback calls to a stateless or stateful session bean instance.
From the diagram on Frit's noted on p.18, loopback is just method 1on a bean calls method 2 on another bean, and method 2 calls method 3 on the first bean. Or method 1 calls method 3.
I don't see loop back is related to multiple threading.
Yeah, I had the same doubts. The only logical explanation to this is that the container cannot always distinguish the thread related to the first method call (coming from the client) from the thread related to the second method call (coming from bean B). The good thing for us (developers) is that we don't have take the re-entrance into account.
Hi Frits. Thanks for your reply.
I guess the container needs two threads to do the loopback call. One thread is to handle the first method call (coming from a client) and another thread is to handle the second loopback method call (coming from bean B).
But with stateful and stateless bean, only one thread is allowed to execute on this bean. That may be why loopback call is not supported in stateful or stateless bean.