Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Session Beans - Reenterant

 
s khosa
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Does someone have any convincing explanation about why session beans cant be re-enterant? I have been reading few but am still not convinced..:-)

Thanks
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Easy answer - that's what the spec says.

Rationale -

Since container manages a pool of session beans, several book keeping activities occur before a bean instance is allocated for a client, when a method is inoked. The problem is with the loopback - in this case the container will not be able to distinguish between a normal client call and a loop back.

By restricting one thread per execution, both the implementation and EJB programming model becomes simple and easy.



EJB Spec 1.1 6.5.6 Serializing session bean methods -

A container serializes calls to each 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 session bean does not have to be coded as reentrant.


 
s khosa
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But by this logic..container also passivates EntityBeans. So there would be a pool of entity beans also avalaible. Would it not be tough for container to detect entity bean re-entrants also? Or am i missing some fundamental point here.

Thanks
 
Required Field
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't quite understand...

When the client makes a call to my session-bean, its a synchronous call, which means the client is actually waiting for the method it invokes to return (or else it would be a MessageDrivenBean!). In other words its a blocking call and the client is not in a position to invoke the same method while its waiting for it to return!

The only way SomeSessionBean.methodB() can be invoked from within SomeSessionBean.methodB() is if the SomeSessionBean's methodB() is defined (coded) to invoke itself in a loopback, not if the client decides to invoke them in that fashion (it can't)!

The only other possibility is that the client is creating threads for calling methods on my bean, which is not allowed by the spec either! Well not for Stateful Session EJBs, no. Same applies to Entity EJBs.

So, the re-entrant behavior is not allowed for what reason then?



Originally posted by Ajith Kallambella:
Easy answer - that's what the spec says.

Rationale -

Since container manages a pool of session beans, several book keeping activities occur before a bean instance is allocated for a client, when a method is inoked. The problem is with the loopback - in this case the container will not be able to distinguish between a normal client call and a loop back.

By restricting one thread per execution, both the implementation and EJB programming model becomes simple and easy.

 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is not from the client's perspective, but from the container's perspective. The container will have to do more work to keep track of loopbacks, at the cost of sacrificing simplicity.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic