This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

sessioncontext in EJB  RSS feed

 
Raju Sathwik
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
Could anyone explain the reason for the following
We have setEntityContext() and unsetEntityContext() methods in Entity beans but why we have only setSessionContext() method but not unsetSessionContext() method in Session Beans.
Regards,
Raju
 
Dave Landers
Ranch Hand
Posts: 401
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree that it would be better for symmetry to have both, but I think the reason has to do with the lifecycle differences between the bean types.
If you look at the EJB lifecycles in the spec or in an EJB book, you will see that:
A session bean calls setSessionContext in transition from DoesNotExist to MethodReady state. It also calls ejbCreate in this transition. The opposite transition from MethodReady to DoesNotExist calls ejbRemove. So if there is work to be done on these state transitions, you should put that work in ejbCreate and undo it in ejbRemove. The setSessionContext method should do nothing but set the context.
For an entity bean, there are many more states. The transitions between DoesNotExist and Pooled calls set/unset EntityContext, and ejbCreate/ejbRemove are called on the transitions between Pooled and Ready.
So if your entity needs to do "work" on the transition between DoesNotExist and Pooled, you do that in setEntityContext, and you need unsetEntityContext to "undo" that work.
Not the clearest thing in the world, but that's where the job security comes from.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!