aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Session Bean Re-entry Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Session Bean Re-entry" Watch "Session Bean Re-entry" New topic
Author

Session Bean Re-entry

Ravi Bansal
Ranch Hand

Joined: Aug 18, 2008
Posts: 86
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 ?



SCJP 5.0 94%
OCE-EJBD 90%
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1696
    
  25

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
Ranch Hand

Joined: Aug 18, 2008
Posts: 86
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
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1696
    
  25

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
Ranch Hand

Joined: Aug 18, 2008
Posts: 86
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
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1696
    
  25

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
Ranch Hand

Joined: Aug 18, 2008
Posts: 86
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
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1696
    
  25

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
Ranch Hand

Joined: Aug 18, 2008
Posts: 86
Ok, reading this way, makes more sense .

Thanks Frists. I found Your explaination really useful .
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Session Bean Re-entry