• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

EJB spec 101: 7.11.8 --> Non-re-entrant instances

 
Sankar Subbiramaniam
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
EJB spec 101: 7.11.8 --> Non-re-entrant instances:
Can somebody provide more clarification of the statement:
"One implication of this rule is that an application cannot make loopback calls to a session bean instance."
 
B.Sathish
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Consider a scenario where Bean A calls a method on Bean B. If the called Bean B method calls a method back on Bean A in the same thread, it is called a loopback. The container does not allow loopback calls by default. ie Bean instances are non-reentrant. The container would treat a loopback call just like a call coming from a second client when the bean is already executing a method for the first client. In other words, if Bean A calls a method on Bean B and Bean B calls a method on Bean A in the same thread, the container would treat this call as coming from a new client / new thread. Hence the call won't go through (Bean B would get an exception). But you can cause loopbacks to be allowed by setting re-entrancy to true in the DD. Re-entrancy can be set to true only for entity beans. Session beans and MDB's are always non-reentrant. But you should avoid setting re-rentrancy to true, because you are asking the container to do a risky thing which it would normally not do, you are trying to step on it's thread management.

For the SCBCD, I don't think you need to know about re-entrancy. To be on the safe side, just know that session beans and MDB's are always non-reentrant and that entity beans can be made re-entrant through the DD, but is risky and should be avoided.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic