Session objects are never shared and are not meant to be persistent (though they do have an activation/deactivation mechanism in place for stateful session beans). A SessionBean always serves one client at a time. Stateless session beans may serve multiple clients but not simultaneously. A generally accepted architecture is the opposite of what you describe, namely session beans wrapping entity beans. It's the entity beans that are shared between multiple clients, not the other way around. I have another question that came up recently in our work: How about non-bean to bean relationships? We're all talking about bean to non-bean, but what if at the end of some graph of non-bean objects you want to have a refernce to a entity bean? What are the implications of that for persistence mapping and transactions? Frank -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Javier Deniz Sent: Thursday, July 29, 1999 9:14 AM To: [EMAIL PROTECTED] Subject: Re: Hanlding EB relationships,was RE: fat getter/setters versus get/ set with all data Chris Raber wrote: > - Bean to dependent object. My opinion is that these are always aggregating > relationships. If a bean needs to relate to a non-bean object, which is does > not "own", then the dependent-object should probably be escalated to bean > status. I am not quite sure about that. Consider, for example, a Session object in the sense described by Yoder/Barcalow in their PLoP'97 paper "Architecture Patterns for Enabling Application Security" (to appear in PLoPD-4 book). Their "solution" section starts saying: Create a Session object, which holds all of the variables that need to be shared by many objects. Note that we may want persistent session objects which are referenced by many entity beans to hold shared values during long business scenarios. Those session objects are typically created once by some kind of administration utility and then used only by the entity beans that share the several values hidden in the session object. Wrapping session beans or clients do not access them in typical business situations. We think that making them beans adds unnecessary overhead. We would rather leave the OODBMS handle the access to such objects here. Adding "EJB access" wouldn't add much value here (would it?). Using a non-OO DB may be different, though. Javier Deniz =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
