File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Why session beans doesn't have unsetSessionContext() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Why session beans doesn Watch "Why session beans doesn New topic
Author

Why session beans doesn't have unsetSessionContext()

Rameshkumar B
Greenhorn

Joined: May 02, 2002
Posts: 1
Hi ,
I need clarification regarding why only entity beans had unsetEntityContext(), why not session beans had the same unsetSessionContext().
Thanks in advance.


B. Ramesh Kumar
ersin eser
Ranch Hand

Joined: Feb 22, 2001
Posts: 1072
Answer
ejbRemove() is called for session beans every time the container destroyes the bean. So you can use this method to do the stuff you typically would do in unsetEntityContext().
For entity beans ejbRemove() is only called if the user explicitly deletes the bean. I think that is the reason why the engineers at SUN invented the unsetEntityContext() for this kind of bean.

Google search of "Why session beans doesn't have unsetSessionContext()" Otherwise I had no idea...
ersin eser
Ranch Hand

Joined: Feb 22, 2001
Posts: 1072
Also read this:

The ejbRemove() method is used inconsistently in session and entity beans. For session beans, the ejbRemove() method is invoked when a bean moves from the "method-ready" state to the "does not exist" state. This transition doesn't occur on a predictable basis, even though many developers believe that it occurs every time a client invokes the remove() method on a remote stub. For session beans, the ejbRemove() method is used as a container callback to notify the bean that it's being placed into "inactive" status. It is not used to indicate that the bean has been destroyed, but a container is allowed to make this transition as part of a remove() invocation from the client.
This contradicts the intended use of ejbRemove() for entity beans, for which ejbRemove() is called when the bean is being destroyed in the persistent store. If you take a close look at the entity EJB state diagram, another container callback is used to notify a bean that it is being moved from the "pooled" state to the "does not exist" state: unsetEntityContext(). As an instructor to hundreds of students who're learning EJBs, it's often a nightmare to explain to them that ejbRemove() for session beans and unsetEntityContext() for entity beans represent the same event transitions, but ejbRemove() for entity beans really means destruction.
Here's a proposal, though the migration to support it would be difficult: how about changing ejbRemove() in the SessionBean interface to be unsetSessionContext() and alter ejbRemove() in the entity bean interface to be ejbDestroy()? In this scenario, the ambiguous ejbRemove() wouldn't exist in either interface and consistency would exist between setXXXContext() and unsetXXXXContext() callbacks.

OReilly
[ May 02, 2002: Message edited by: ersin eser ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why session beans doesn't have unsetSessionContext()