Session Bean Re-entry

[Ravi Bansal]

EJB 3.x specs Section 4.3.14

The container serializes calls to each stateful and stateless session bean instance. Most containers will support many instances of a session bean executing concurrently; however, each instance sees only a serialized sequence of method calls. Therefore, a stateful or stateless session bean does not have to be coded as reentrant.

Does this mean , below should not work in any app-server (its applicable to stateful as well) ?
other question that is coming to my mind is that in this case , container will create/fetch another instance of MyService bean when save() is invoked. It may or may not be the same instance of MyService bean in when myMethod got invoked by client ? OR it behaves differently depending upon whether the bean is stateful or stateless ?

@TransactionAttribute(TransactionAttributeType.REQUIRED)
@Stateless
public class MyService {

    @Resource
    SessionContext ctx;

    public void myMethod()  {
        // do something...

        // invoke method from the same class


        ctx.getBusinessObject(MyService.class).save();
    }

    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public void save() {
        // do something...
    }
}

[Frits Walraven]

Hi Ravi,

Does this mean , below should not work in any app-server (its applicable to stateful as well) ?

I am not sure what you are trying to ask, but the code works fine if you add a Business Interface or No-interface local view (@LocalBean) to it. I guess that you also meant that both myMethod() and save() are exposed through the same Business interface (or no-interface-view)?

To my understanding: if you have let's say two clients, Client 1 calling myMethod() and Client 2 calling save(), they might end up on the same instance of the session bean or on two different instances, remember that doesn't matter as they are stateless. However the call from myMethod() to the other method save() (.... maybe far-fetched, and more likely, calling another SessionBean that calls save() on this SessionBean) will end up on another instance (as the one serving Client 2), or if none is available, has to wait until Client 2 exits save().

The story differs from a Stateful Session Bean as that bean only serves one Client.

Regards,
Frits

[Ravi Bansal]

Thanks for the reply Frits.


I am asking the question in the context of re-entry (directly or indirectly) . for example , re-enterance is when a beanA invokes method some method on beanB and beanB invokes some method on beanA in the same thread of control.

In the code that I posted , instead of in-direct re-enter, this is trying to re-enter in the bean instance directly (loopback call)
As far as I know , its not allowed in session beans. Thats why I mentioned about the section of EJB Specifications.


For stateless session beans, I believe getBusinessObject will return the new bean instance (As its same as that JNDI look up).
But For stateful session , getBusinessObject will try to re-enter in the same instance when save method is invoked so this should not be allowed. Am I right ?

Please confirm is you see something is missing in my understanding .



Thanks
-Ravi Bansal

[Frits Walraven]

Hi Ravi,

Ok, I understand you, you are right!

Re-entry is allowed for Singleton Session Beans, but not for Stateful Session Beans and Stateless Session Beans.
Apart from that a loopback call is either done indirectly (via another EJB) or directly via the getBusinessObject() method.

Just getting the paragraphs from the ejb3.1 specs:

4.10.13 Non-reentrant Instances
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.

in ejb3.2 they want to add some clarification to getBusinessObject() :

The getBusinessObject(Class businessInterface)method returns a business object reference to the session bean’s business interface or no-interface view. In the case of the no-interface view, the argument is of the type of the bean class. Only session beans with an EJB 3.x business interface or no-interface view are permitted to call this method.
If a subsequent invocation were made on the result of getBusinessObject, then:
- For a stateless session bean, the invocation would be delivered to another stateless session bean instance.
- For a stateful session bean or singleton session bean, the invocation would be delivered to the bean instance that returned the reference. The existing rules regarding reentrancy would then apply.

This last explanation ("The existing....") is being discussed to be changed right now:

The object reference returned from SessionContext.getBusinessObject is to be used for the subsequent invocations (see 4.3.3), not reentrant calls.

Regards,
Frits

[Ravi Bansal]

Thanks alot for your time Frits.

Reading at your answer , I am having few more doubts now.

4.10.13 Non-reentrant Instances
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.

When a loopback call is a made , there is still a single thread of control (be it on same stateful session instance or new stateless instance), then why the reasoning for stopping the re-entering in the bean is given in terms of thread ? will this re-enterant bean result in multiple threads accessing the session beans (stateful or stateless ) instance somehow?

You mentioned about ejb 3.2 spec, is it published somewhere (Draft version) ?


You also mentioned

This last explanation ("The existing....") is being discussed to be changed right now:

The object reference returned from SessionContext.getBusinessObject is to be used for the subsequent invocations (see 4.3.3), not reentrant calls.

What do you mean by subsequent invocations over here ? As I understand in ejb 3.2, In case of stateful session bean , it will be re-enterance call in the same instance and in case of stateless session bean , it will re-entry in a new/different instance. That also implies to me getBusinessObject will only be useful in case of singleton session beans.

I am not sure if these questions make sense but seems that I am missing something here.

[Frits Walraven]

I am not sure if these questions make sense but seems that I am missing something here.

Yes, they make sense, these are good questions! We are trying to grasp the concept of re-entrancy of Session Beans in relation to the specs and we can conclude that the description is not very clear.

When a loopback call is a made , there is still a single thread of control (be it on same stateful session instance or new stateless instance), then why the reasoning for stopping the re-entering in the bean is given in terms of thread ?

Yes, I guess those are two different things they are trying to specify:
- Only a single thread can acces a stateless or stateful session bean
- Re-entrancy, is not allowed for both

What do you mean by subsequent invocations over here ?

"If a subsequent invocation were made on the result of getBusinessObject()"
I have just noticed, that that explanation didn't make it to the draft version

That also implies to me getBusinessObject will only be useful in case of singleton session beans.

Not really, it is also useful for stateless session beans as the container will just grab another instance (and as you as a caller do not care on what instance your method is running.)

Regards,
Frits

See ejb3.2 draft and discussion java.net

[Ravi Bansal]

Thanks Frits for spending time on this.

Reading all this makes one point certain

Stateless Seession bean will never be re-entered because every call to business method will take it to new/different instance.
If specficaition say that "Stateless session beans do not have to be coded as re-enterant".

Is there any way that this can be achieved ? I mean can I code re-enteant stateless session bean somehow?

[Frits Walraven]

stateful and stateless session beans do not have to be coded as reentrant.

The way I read this is that we don't have worry when coding about the fact that the instance can be re-entered, because the container takes care of it:
- for Stateless Session Beans it will grab another instance (avoiding re-entrancy)
- for Stateful Session Beans it will throw an IllegalLoopbackException (blocking re-entrancy)

Regards,
Frits

[Ravi Bansal]

Ok, reading this way, makes more sense .

Thanks Frists. I found Your explaination really useful .

[Himai Minh]

I demo the reentry of stateful bean using Ivan's example like this:

@Stateful
public class StatefulSession3Bean implements StatefulSession3Remote {
    private static int sCurrentInstanceNumber = 1;
    private int mInstanceNumber;
    @Resource
   SessionContext mSessionContext;
     //Try to inject another instance of the stateful bean, but failed. Glassfish runs into an out of memory error at the end.
    @EJB  
    StatefulSession3Remote bean;
    @PostConstruct
    public void initialize(){
    	 ....
    }
    @Override
    public String greeting (final String inName, Account accountParam){
    	 ...
    	 System.out.println("***StatefulSessionBean loopback direct call");
    	 bean.loopBack();
    	 
          //This will return a illegalLoopbackException  
    	//mSessionContext.getBusinessObject(StatefulSession3Remote.class).loopBack();
    	return theMessage;
    }
    @Override
    public void loopBack(){
    	 System.out.println("***StatefulSession3Bean loopback call.");
    	 
    }
 }

The container cannot even inject the StatefulSession3Remote bean using @EJB. I got this output:

aused by: javax.naming.NamingException: Exception resolving Ejb for 'Remote ejb-ref name=com.ivan.scbcd6.client.StatefulSessionBeanSessionListener/bean,Remote 3.x interface =com.ivan.scbcd6.StatefulSession3Remote resolved to intra-app EJB StatefulSession3Bean in module MyStatefulSessionBeanEJB.jar,ejb-link=MyStatefulSessionBeanEJB.jar#StatefulSession3Bean,lookup=,mappedName=,jndi-name=java:global/MyStatefulSessionBeanEJBEAR/MyStatefulSessionBeanEJB/StatefulSession3Bean,refType=Session' . Actual (possibly internal) Remote JNDI name used for lookup is 'java:global/MyStatefulSessionBeanEJBEAR/MyStatefulSessionBeanEJB/StatefulSession3Bean!com.ivan.scbcd6.StatefulSession3Remote' [Root exception is javax.naming.NamingException: Lookup failed for 'java:global/MyStatefulSessionBeanEJBEAR/MyStatefulSessionBeanEJB/StatefulSession3Bean!com.ivan.scbcd6.StatefulSession3Remote' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: ejb ref resolution error for remote business interfacecom.ivan.scbcd6.StatefulSession3Remote [Root ....

But if I demo with stateless bean:

@Stateless
public class StatelessSession3Bean implements StatelessSession3Remote {

	 ...
	 @Resource
	 SessionContext sessionContext;
	 @EJB   
	 StatelessSession3Remote bean;
	 @PostConstruct
	 public void initialize(){
		   ...
	 }
	 
	 @Override
	 public String greeting(final String inName){
		  ...
		 System.out.println("StatelessSession3Bean.loopBack indirect loopback");
		 sessionContext.getBusinessObject(StatelessSession3Remote.class).loopBack();

		 System.out.println("StatelessSession3Bean loopBack direct loopback");
		 bean.loopBack();

		 System.out.println("StatelessSession3Bean loopback by JNDI lookup");
		 ((StatelessSession3Remote)lookup()).loopBack();
		...
	 }
	 
	 public void loopBack(){
		 System.out.println("****StatelessSession3Bean. loopBack");
	 }
	 
	 private Object lookup(){
	    	Object theBeanReference2=null;
	    	try{
				InitialContext theInitialContext = new InitialContext();
				theBeanReference2 = 
					theInitialContext.lookup("java:app/StatelessSessionBeanEJB/StatelessSession3Bean!com.ivan.scbcd6.StatelessSession3Remote");
	    	}
	    	catch (final NamingException theException){
				theException.printStackTrace();
			}
			return theBeanReference2;	  
	    }
}

The output is :

//my note:The first bean is created by the container
Info: ****   StatelessSession3Bean 1.created  
Info: StatelessSession3Bean.loopBack indirect loopback

//my note: the getBusinessObject() method instantiate another stateless bean 2
Info: **** StatelessSession3Bean 2.created. 
Info: ****StatelessSession3Bean. loopBack
//my note:The dependency injection and the JNDI lookup creates two stateless beans references, and the references refers to the same bean 1 created  on the first line. 
Info: StatelessSession3Bean loopBack direct loopback
Info: ****StatelessSession3Bean. loopBack
Info: StatelessSession3Bean loopback by JNDI lookup
Info: ****StatelessSession3Bean. loopBack