All_in_one_table

This Table is very important in the sense that it explains all the methods, how /when they are invoked and what are the back ground happenings behind the method invocation etc.,
Understanding each row is very important

Note : A few errors might have crept in.. If there are any ,they would be corrected so please always check the newest page ....

	Stateless	Stateful	Entity
Pool Creation (pool of beans is always non-dedicated beans)	Yes 1.call setSessionContext(<..>), Followed by ejbCreate(). If pooling is supported every bean must be taken from pool	No	Yes 1.call setEntityContext(<..>) *does not call ejbCreate(<..>) because parameterized create invocation makes a bean dedicated If pooling is supported every bean must be taken from pool for even getting dedicated bean .. if not passivate some other bean
Dedicated Beans?	No picks one bean from pool ,invokes service method sends back to pool as session beans don’t need dedicated bean	Yes instantiated on demand and initialized with specific client data by calling ejbCreate(<..>) or if total number of instantiated beans reached limit, passivate an inactive dedicated bean , reset and reinitialize for the present client. ______________________ Methods on dedicated : 1.all service methods 2.ejbPassivate();(container calls, not client)	Yes 1. picks one bean from pool ,invokes ejbCreate(<..>) , Makes bean dedicated Or 2.There is no free bean in pool , so , passivate an inactive dedicated bean , reset and reinitialize for the present client. ______________________ Methods on dedicated : 1.all service methods 2.ejbStore() and ejbPassivate(();(container calls ,not client)
	Methods on dedicated : None
Non- Dedicated beans	Yes 1.picks one bean from pool ,invokes service method sends back to pool * as session beans don’t need dedicated bean **Methods on Non-dedicated : all service methods SentBack to Pool ? Yes	No .. For a small period of time, a non-dedicated bean exists .. Some passive bean was passivated ,becomes non dedicated but immediately becomes dedicated by swapping a client specific data from persistent storage Into bean ** there is a diff between entity bean persistence and stateful bean persistence.. Swapping means cut and paste , cut from persistent storage And paste it to your stateful bean .. So when remove() is called on stateful , bean ,bean instance is destroyed, session data is lost.., (cant be retrieved again)	Yes 1.picks one bean from pool ,invokes finder /home service/ejbRemove method sends back to pool *Home service method is a special method which operates on entire table of DB rather than specific row.. If it executes ejbCreate(<..>) bean become dedicated SentBack to Pool ? Yes and No **Methods on Non-dedicated which send bean back to pool : 1.finder methods 2.Home Service method,ejbHome..(..) 3.ejbRemove() **Methods on Non-dedicated which don’t send bean back to pool : 1.ejbCreate(<..>)
ejbStore()	NA	NA	1.to synchronize data b/w bean and DB or 2.called before passivation Called on : Dedicated
ejbLoad()	NA	NA	1.to synchronize data b/w bean and DB or 2.after activation : In this case , the bean is for a brief period in non-dedicated state so use ctx.getPrimaryKey();
ejbRemove()	Destroys bean Object is GCed as container nullifies the reference to bean **can be Called by container to reduce pool size Or when client calls remove() on home or EJBObjects, The container may/may not call ejbRemove(); as it may be pooled for reusing	Bean will be destroyed so session data is destroyed *client can call remove() on home or EJBObjects To logout his session Strictly speaking container has to call ejbRemove() in this case, but due to container crashes ,may not be called Or *container may call when session expires	** takes a non-dedicated beansideNotes1 from Pool , Removes DB record Goes back to pool *only client can call remove() on home or EJBObjects ** as a non-dedicated bean services this, use ctx.getPrimaryKey();
ejbPostCreate(<..>)	NA	NA	Called after ejbCreate(<..>)
ejbPassivate()	NA	close resources ** don’t write persistence logic here Container may use java serialization to persist	close resources ** Don’t write persistence logic here Use ejbStore() ejbStore() call precedes ejbPassivate()
ejbActivate()	NA	open resources ** don’t write persistence logic here Container may use java serialization to persist	open resources ** Don’t write persistence logic here Use ejbLoad() ejbActivate() precedes ejbLoad();
Finder methods	NA	NA	Go-back bean from pool taken ,returns single PK/Collection of PKs, goes back to pool *Container constructs new dedicated beans(takes beans from pool) ,associates them EJBObjects, Sends back Collection of EJBObject references /single EJBObject references *Please don’t initialize bean’s state in finder method.., Finder method should not make a bean dedicated