Frank, Unfortunately I think the poster's "session" object is being confused with session beans here. I believe a better term may be "flyweight". On regular object to bean relationships: - Examples: In my earlier post there was an example of this. Consider Order -> Line Item -> Product, where Order is a bean, Line Item is a dependent object and Product is a bean (reasoning for what is a bean and what is not is in the earlier post). So Line Item -> Product is a non bean object to bean relationship. - Assumptions: Line Item would store the Key to the related product in its state. At run-time it would look up the associated Product bean via ProductHome. Line Item could establish the reference to the Product bean using lazy instantiation or could establish the reference immediately. - Transaction implications: Since Product is a bean, it manages its own life cycle (via container call backs). Line Item's life cycle is married to Order's. The container and OR mapping environment you are using (whether CMP or BMP) will makes sure that changes to Line Item's are committed in the transaction that Order is participating in. - Persistence implications: For beans, this is managed via the container callbacks (ejbLoad, ejbStore...). For "dependent-objects" this handled by the containers more advanced persistence options (not precisely decreed by the spec). For home grown BMP implementations, you are on your own. This might be trivial in an ODBMS persistence layer though. Regards, -Chris. ---------------------------------------------------------------------- Chris Raber, Director Professional Services, GemStone Systems Inc. 100 West Big Beaver, Suite 200, Troy, MI 48084 phone: (248)-680-6691, fax: (248)-680-6689, email: [EMAIL PROTECTED] web: http://www.gemstone.com/ ---------------------------------------------------------------------- > -----Original Message----- > From: Frank Sauer [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, July 29, 1999 7:30 PM > To: [EMAIL PROTECTED] > Subject: Re: Hanlding EB relationships,was RE: fat getter/setters > versus get/ set with all data > > 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". =========================================================================== 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".
