• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Client can use Stateless SessionBean after calling remove()

 
Chris Lewold
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tested with the 1.3 RI.
// Here is the code

.......
No exception is invoked after I call getAdviceOfTheDay() for the 2nd time (after invoking remove() ) .... why ???
Thanks for Clarification
Chris Lewold
[ January 14, 2004: Message edited by: Chris Lewold ]
[ January 21, 2004: Message edited by: Chris Lewold ]
 
Keith Rosenfield
Ranch Hand
Posts: 277
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Chris:
That's strange. Have you tried it using the other remove method(advisor.remove())?
 
Chris Lewold
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aye I did - that's why I left it in the code (commented out).
I now changed my test code to also do advisor.remove();
No probs at all for him to do both.
BTW .... In the session bean I implemented the ejbCreate, ejbRemove, .... methods using simple printlns.
-) The server lists "ejbCreate invoked" when the clinent is run for first time.
-) The server never lists an "ejbRemove invoked" (which I somehow expected).
-) The server also does no more "ejbCreate invoked" when the client is run for the second time. (Which is somehow ok for me as this is a stateless session bean, and I assume it comes from the pool).
 
Keith Rosenfield
Ranch Hand
Posts: 277
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Chris:
The server never lists an "ejbRemove invoked" (which I somehow expected).

You shouldn't expect this. The container decides when to remove the bean from the pool. This does not necessarily happen after the client calls remove on the bean. The server probably wouldn't remove the bean but leaves it in the pool, ready for the next client invocation. As for your first question, I'm still thinking about it and will let you when and if I figure it out.
 
Chris Lewold
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are fully right of course - I read it on the next pages. ejbRemove is only invoked when there are too many beans in the pool, so the container decides to get rid of some. Ok.
But I still consider it invalid to invoke any business method on the component interface after the client did a remove() on it.
I Did some further testing which is rather interresting imho:
1) When changing the bean to stateful all works "as expected"
2) I implemented a slighly different version of the client code (see below).
The idea was to implement a defective method in the bean which just throws a RuntimeException. This exception should arrive on the client side as RemoteException. The bean should move into state "does not exist" after the defective method is invoked. I named the method defectiveMethod()
Client code:

Here is the Output:

-) The exception was correctly thrown and correctly arrives at the client.
-) The bean should be in state "does not exist" now - right ??
-) Invoking a method on this bean after catching the exception works perfectly.
[ January 15, 2004: Message edited by: Chris Lewold ]
 
Chris Lewold
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bumping this because I read HFE Book Page 282 now.
It clearly says "Client will get an exception if he tries to use the EJB object reference after removing the bean". (Stateless session beans).
Using the RI this is NOT the case, as shown above.
Regards,
Chris Lewold
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic