• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Help! Confusion about Petstore [uses loopbacks?]

 
David Carel
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In Petstore, the following sequence of method calls appears to happen:
ShoppingClientControllerEJB.handleEvent(CartEvent)
which delegates to:
StateMachine.handleEvent(CartEvent)
which delegates to:
CartHandler.perform(CartEvent)
which then calls:
StateMachine.getShoppingClientControllerEJB().getShoppingCart();
Isn't this a loopback to the ShoppingClientController session bean? According to the spec:
The container must ensure that only one thread can be executing an instance at any time. If a client request arrives for an instance while the instance is executing another request, the container must throw the java.rmi.RemoteException to the second request.
Note that a session object is intended to support only a single client. Therefore, it would be an application error if two clients attempted to invoke the same session object.
***One implication of this rule is that an application cannot make loopback calls to a session bean instance.***

What am I missing?
 
Bagwan Mehrat
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm a novice at EJB, but I can hazard a guess at your questions. I hope that someone with more knowledge that I have will correct me if I'm making any incorrect assumptions here.
First and second, this stack doesn't seem to show any multithreading, or multiple clients. It just looks like the ShoppingClientControllerEJB instance is simply being called twice.
As for "loop back", if I were Sun, I wouldn't have put any restrictions on an EJB calling methods in itself! That would clearly be unacceptable.
I haven't read the specs you are quoting, but my guess is that part of why this restriction exists is in order to keep order and sanity when dealing with tranaction contexts. If you were in the middle of a Session EJB transaction and you made a call back to yourself through RMI, then that callback would probably have a different thread and transaction context, and would result in a deadlock unless the container was able to detect this condition and throw an exception.
So my guess would be that when they said "call back", they meant, "call back through container boundaries".
 
David Carel
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello and thanks for your reply.
You said, "So my guess would be that when they said 'call back', they meant, 'call back through container boundaries'."
I think that's a very attractive explanation, and it makes great sense to me. In the EJB spec, they mention the following regarding this restriction (sec. 6.5.6 of EJB 1.1 spec):
-----------
One implication of this rule is that it is illegal to make a �loopback� call to a session bean instance. An example of a loopback call is when a client calls instance A, instance A calls instance B, and B calls A. The loopback call attempt from B to A would result in the container throwing the java.rmi.RemoteException to B.
-----------
In this explanation, it wasn't clear to me that A and B reside in *different* containers... your proposal grants sound insight into what must have really been meant. Thanks again!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic