It all be best to have a single entry for session data. However, if scalability is an issue, we all need to consider size of the Object being hook to the session. Size does matter when you apps run in a clustering enviornment. Of, replicating a small object at a time is always better the a whole big object.
Danny. Ps. Best practice is to keep your session object as small as possible. -----Original Message----- From: Robert Taylor [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 05, 2002 3:14 AM To: Struts Users Mailing List Subject: RE: [core] Architectural considerations Personally, I created a session container which provides an API to access items from the session. This way I don't have to manage a bunch of session attribute keys and the API provides the appropriate class casting. So for example if I had a User bean and a ShoppingCart bean that I needed to persist in the session, then my SessionContainer object would have an API like getUser(),setUser() and getShoppingCart(), setShoppingCart(). I maintain a single session attribute key like "sessionContainer". SessionContainer container = (SessionContainer) session.getAttribute(SessionContainer.KEY); User user = container.getUser(); ShoppingCart cart = container.getShoppingCart(); I actually got the idea from Chuck Caveness' Struts book. I forget which chapter, but when I saw it, I pounced on it. I'm not sure if it is considered a "best practice" but it makes sense and it is published. robert > -----Original Message----- > From: Mark Kaye [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 05, 2002 6:00 AM > To: Struts Users Mailing List > Subject: [core] Architectural considerations > > > Would it be better for me to store information I need across a session > in a session scoped form bean or as individual variables stored in the > HttpSession. What are the advantages/disadvantages of either > approach? I imagine they approximate to the same thing, but there must > be 'best practices' in this area. > > Regards, > > M > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
