About Question enthuware.oce-ejbd.v6.2.568 :

[himaiMinh]

For option 2, it is true that stateless and stateful bean does not allow reentrant.
If A is a stateless bean, in b(), can we do this ?

Code: Select all

public void b (){
   //the container gets any instance of A in the bean pool,
 // which is not the same instance that invoke b()
//In this way, it is not coded as reentrant.
 A aBean =   sessioncontext.getBusinessObject(A.class);
    aBean.a()
}

[admin]

The specification restricts the loopback call on the same thread. If one bean is in another container then what you say will work.

[himaiMinh]

Hi, admin,
I tried to code option 2 and it works for stateless bean:

Code: Select all

@Stateless
@Local(SLSBALocal.class)  //This interface is not shown.
@LocalBean
public class SLSBA  {
	@EJB SLSBB beanB;
 @Resource SessionContext context;
    public void method1(){
    	System.out.println("SLSB A method a calls SLSB B method2 ");
         beanB.method2();
    	 
    }
    
    public void method3(){
    	System.out.println("Call method 3 .");
    }
}

Code: Select all

@Stateless
public class SLSBB {
	@Resource SessionContext context;
         //inject another instance of stateless bean SLSBA
         //inject the same instance of bean SLSBA if SLSBA is a    
         //singleton bean.
	 @EJB SLSBA beanA;
	
         public void method2(){
    	    System.out.println("SLSB B method b");
    	    beanA.method3();
         }   	
 }

The code works.
By the way, in the question, method a() called b() and b() calls a() and so on, it will never end.

[himaiMinh]

For option 2, for an instance of stateless Bean A's a() method calls another Bean B's b(). It is possible that Bean B uses another instance of Bean A in the pool and calls a() method.

In this case, there are two instances of stateless Bean A and reentrant calls do not apply.

[henrid]

That's what I also think: the container will/should prevent re-entry by creating a new instance in case of a SLSB.

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

So even when the spec says that an application cannot make loopback calls, that does not imply the way is should be implemented: Should the container throw IllegalLoopbackException or create a new instance to prevent loopback? Or is it up to the container and unspecified?

[admin]

The statement in the specification is quite clear, "One implication of this rule is that an application cannot make loopback calls to a stateless or stateful session bean instance."
So, you cannot make loopback calls. Plain and simple. I do not see any question of implementation in this statement.

-Paul.

[henrid]

Okay, it seems you don't know the exact answer either. The spec is sometimes too plain and simple, just like the API. I know that there are millions of details and I see the spec is interpreted in dozens of ways by containers. So I assume IllegalLoopbackException, not reading it anywhere but in the topic of singletons.

[admin]

Okay, it seems you don't know the exact answer either. The spec is sometimes too plain and simple, just like the API. I know that there are millions of details and I see the spec is interpreted in dozens of ways by containers. So I assume IllegalLoopbackException, not reading it anywhere but in the topic of singletons.