Re: Stateful Session Beans

[GlennODickson]

Title: Message

Thanks Juan for your comments they very much in line with Dmitri's and it really helps   So it seems that it normal practice to store a SFSB in a session class for the during of client's session.   So if may paint a picture here in summation in regard to my architecture I described:   1. the user logs in and WEB Tier controller creates a SFSB and adds this reference to the session object of the request. 2. the client and other class may references this SFSB at any time   Therefore the SFSB is not hidden by any facade such the CustomerService?   Glenn ----- Original Message ----- From: Juan Pablo Lorandi To: 'GlennODickson' Sent: Thursday, September 12, 2002 12:55 PM Subject: RE: Stateful Session Beans Handles... check out javax.ejb.Handle and javax.ejb.HomeHandle.   to get the handle of an instance i, you use i.getHandle(); this is defined in javax.ejb.EJBObject. Section 6.5 of the spec refers to EJBObject in a Session Bean.   Handles are serializable and network transparent.   Basically, SFSB hold state, but you need to keep track of the reference to the SFSB... that's what the handle is for   example (in jsp):   page1.jsp: <% .... mySFSB s = sHome.create(); s.setUsername("jpl"); session.setAttribute("CustomerSession", s.getHandle() ) ; ... %>   page2.jsp <% .... mySFSB s = (SFSB) ((Handle) session.getAttribute("CustomerSession")).getEJBObject(); String username = s.getUsername(); .... %>   HTH,   Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050  Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com   Disclaimer:   Opinions expressed are entirely personal and bear no relevance to opinions held by my employer. Code Foundry Ltd.'s opinion is that I should get back to work. -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]] On Behalf Of GlennODickson Sent: Thursday, September 12, 2002 5:37 AM To: [EMAIL PROTECTED] Subject: Re: Stateful Session Beans Hey thanks for your comments I would like to ask then:   I do have this structure :   action class(struts) <---->webTier Controller (class) <-------> EJB Business Delegate(SLSB) <--------> Customer Service (SLSB) <------> Customer (Entity Bean)     1. Where  would be an appropriate in this structure to place a bean that holds the customers login details and session state ? Would you create another bean called CustomerSession (SFSB) or make the Customer Service a SFSB?   2. How would this SFSB be referenced ? I don't understand how the SFSB can be retrieve at some time later to use the session details.   TIA Glenn       ----- Original Message ----- From: Kesavanarayanan, Ramesh (Cognizant) To: 'GlennODickson' Sent: Wednesday, September 11, 2002 4:58 PM Subject: RE: Stateful Session Beans Answers in line   ? Ramesh Kesavanarayanan  ?    [EMAIL PROTECTED]           Anger results in delusion, delusion leads to loss in memory,           memory loss leads to knowledge loss, If knowledge is lost            you perish     Can anyone tell me the following about stateful session beans ? 1.       Who calls them, I am to understand that these beans should be called by the specific client (stub-client)? Yes if you do not have any other design pattern like session fa�ade(SLSB) or Business Pattern 2.       Can a facade call these and hide its use? Yes obviously you can refer any design pattern books for these. 3.       Do they have to be called from the client and if not, what are the common ways in which these are used. Yes if you do not have any other layer between them and the client. These are basically to hold the state of your bean in handles. Refer mastering EJB by Ed Roman for further studies on EJB.     4. Who exactly calls these (client side apps etc) and how I structure they use properly (according to how that are to be used correctly!)             I do not understand your question can you come again please.   As I said earlier refer to the book by Ed Roman from www.theserverside.com