How a Statefull Session Bean is tied to a particular Client? Does the tieup depends on the parameter we pass in the ejbcreate() method or it is independent.How exactly the tie-up is build & when does it breaks. 1 more. By looking at the code is it possible to distinguish between Stateful Session Bean & Stateless Session Bean. If so, then on what basis. Thnxs.
How a Statefull Session Bean is tied to a particular Client? Does the tieup depends on the parameter we pass in the ejbcreate() method or it is independent? This is handled by the EJBHome/Object stub of your SFSB client and the EJB Container.We do not have to worry about that. The EJB Container manages it smartly.It maintains the session for us and does not dependent on any data that we pass in the methods.We only pass the state information specific to the client depending on our business logic. How exactly the tie-up is build & when does it breaks? - It breaks when home.remove() or remote.remove() is called by the client or a time-out for the SFSB occurs at the server side. SFSB bean instance serving this client is destroyed by the Container.
By looking at the code is it possible to distinguish between Stateful Session Bean & Stateless Session Bean. If so, then on what basis?
Yes it is possible if you understand the differences between SFSB and SLSB. 1. SLSB has only 1 ejbCreate() method in the bean, while SFSB can have overloaded ejbCreate() methods with different parameters. 2. There could be member variables in the bean class to hold client-specific state for SFSB 3. There could be some valid code in ejbActivate() and ejbPassivate() methods for SFSB.These methods do not make sense for SLSB, should be empty as they are never called by the container for SLSB. 4. The "bean-ness" - the ability to do different things inside a method is different for SFSB and SLSB. The ejbCreate(), ejbRemove(), ejbActivate(), ejbPassivate() methods of SFSB can access other resource managers/enterprise beans, as they have a security context available for these methods. This is not possible for SLSB as they do not have a client security context associated with these methods. 5. If the bean implements SessionSynchronization interface also, then it is a SFSB. 6. If the bean methods contain bean managed transactions and if the transaction is kept open across multiple methods, then also it is a SFSB. 7. Lastly in the DD-XML file, the type of Session bean describes whether it is a SFSB or SLSB. [ March 18, 2004: Message edited by: Vish Kumar ]