unsetSessionContext

[Sergiu Truta]

Hi guys,
I have found on another forum a question and I would like to find the answer with you. Why there is a unsetEntityContext() but there isn't a unsetSessionContext()? What I have found is this:
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. And this might be the reason why the engineers at SUN invented the unsetEntityContext() for this kind of bean.
So if you implement a unsetSessionContext() inside the session bean it will never be called.
What do you think?

[Sergiu Truta]

I have found this also:
http://www.mail-archive.com/[e-mail]/msg23873.html

[Pradeep bhatt]

When ejbRemove is called on a session bean the instance is about to be destroyed but when it is called on entity bena the entity is destroyed and not the bean.

[Kathy Sierra]

Howdy,
Yes, just agreeing with what's been said here.
Session beans:
- bean instance is about to be destroyed by container: ejbRemove()
Entity beans:
- bean instance is about to be destroyed by container: unsetEntityContext()
- underlying entity in the persistent store is about to be deleted: ejbRemove()
So, since ejbRemove() has a different purpose for entity beans, they needed to add a NEW method to serve that same purpose (i.e. to alert the object that its about to be killed) for entity beans.
This is one more example of a method that "uses the same name for session and entity beans but gives it a completely different behavior!" Which I personally wish were not true.
It would have perhaps been easier to remember the differences if, say, both session and entity beans used an ejbRemove() for when the object is destroyed, and then added a new method for the DELETE -- ejbDelete() for entity beans. That way ejbRemove() would always have the same behavior, regardless of whether the bean is a session or entity bean. But that's just me
Another example of this is ejbActivate() and ejbPassivate() --
Session beans (stateFUL only; stateLESS beans are never passivated):
- bean is about to be brought back to life (possibly deserialized) in order to service a client's method invocation on the bean's interface: ejbActivate()
- bean is about to be "knocked out" (possibly serialized) in order to conserve resources between method invocations from the client: ejbPassivate()

Entity beans:
- bean is about to be brought out of the pool (NEVER deserilization; an entity bean is still a living object on the heap while passivated) to *become* a particular entity (say, Customer Fred Flintstone #42): ejbActivate()
- bean is about to slide back into the pool (stays a living object on the heap) after having completed a transaction on behalf of some particular entity: ejbPassivate()
Oh, and let's not forget ejbCreate()!
Session beans:
- bean is being initialized (this immediately follows the setSessionContext() method call) for the first and only time: ejbCreate()
(Note: stateLESS - this is invoked whenever the container decides to create a new bean for the pool. stateFUL - this is invoked as a direct result of a client calling create() on the bean's home)
Entity beans;
- already-made bean is being pulled into service to help create/insert a new entity in the underlying persistent store. This method may be called on the same bean instance in the pool over and over again. Or possibly NEVER -- if nobody uses the bean to insert a new entity. This method, ejbCreate(), is in NO way tied to setEntityContext().
Lessons learned: in my most humble opinion, I think it would be nice if API designers chose *different* names to represent *different* things, rather than using the SAME name and giving it two completely different meanings depending on the 'mode' (and by 'mode' here, I mean whether it is an entity bean or a session bean). This is a foundation of usability in user interface design, and it would be wonderful if all API designers also followed this. However, the J2EE team was under constraints, I'm sure. And of course entity beans were not even part of the required spec in EJB 1.0.
cheers,
Kathy