RE: howto avoid overuse of session object?
I agree, stick to the session itself for purposes of scaling later, just be smart about the objects you put in there, IE, use singletons and factories for instances, etc. There's no need to write your own session handler. Jacob Hookom Comprehensive Computer Science University of Wisconsin, Eau Claire -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 1:46 AM To: Tomcat Users List Subject: AW: howto avoid overuse of session object? Just to throw in anothe opion :) I agree with you. As I understand you want to exchange object between two requests of the same session. If you have information that has a scope that is below a session, I don't see any reason to store it with a scope that is above the session (application or context). I don't see any benefit at all but several disadvantages. If you store the information in the session you have following advantages: - If you have errors in your applications that sometimes forget to remove object, you can at least be shure that they will be removed at the end of the session. (Of course you can implement your own code in a Listener that destroys the data from the context or application, but why implement something that is done by the container anyway) - If you have to scale your site up to use a loadbalancer with distributed session, this will work only if all informations that belong to a session are store in the session (Or you have to write code that serializes the data that you store The only reason to store this data in a scope that is above the session level, is to store it in a database instead of the memory (e.g. to implement your own distributed/failsafe sessions). Of course it's good practice to reduce the objects in the session but not at the price to store them just in different scope in memory. What you can do, is reuse objects between sessions if the object are the same or to use references. E.g. if you have an application that implements a shopping cart you just need the references to the products that are in the basket not the products itself. In your case I would recommend to store the data in the session and to remove them on your own as soon as possible. One additional advice: give the objects names by using a naming convention that makes it unlikely that you add, change or remove them by accident. Ralph Einfeldt Uptime Internet Solution Center GmbH Hamburg, Germany Hosting, Content Management, Java Consulting http://www.uptime-isc.de -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 1. August 2002 22:33 An: Tomcat Users List Betreff: Re: howto avoid overuse of session object? Thanks, Cédric and Peter Lin, for your responses. Both of you seem to be saying that, instead of storing large objects in the session object, -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: howto avoid overuse of session object?
Hi, FIRST For non-specific Tomcat questions, it exists : [EMAIL PROTECTED] There's also an other one wich is JSP oriented. SECOND All best practice i know says that you must minimize the ammount of data stored in the session. So, the traditional approach of this problem is to only store the user-id (simple type) in the session. All over session informations (a class containing all required informations) are stored in the servlet context. Praticaly, on the request you get the user id from the user session. Next you use this Id to get the user information obect from the servlet context. This is certainly deceiving, but this is the way ... Maybe someone knows better practice ? Regards, Cédric - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 01, 2002 6:13 PM Subject: OT: howto avoid overuse of session object? This is sort of off-topic, but I don't know of a better forum targeting Java web/servlet programming. If anyone does know of one, could you let me know? I'm basically wondering if others have found effective ways to avoid the tempting but bad practice of loading up the session with all sorts of attributes. I often find myself needing some Bean or other object for maybe 2 or 3 requests, and, rack my brains as I may for an elegant way of passing the object along without putting it in the session, I usually end up with nothing more than a headache and 1 more attribute in my session. :( I'm developing with an MVC approach, with Struts for more recently developed apps and a similar custom framework for our older apps, but I just can't seem to see a way to get around this problem. I would love it if there were an object like a thisRequestAndTheNextOne object, where attributes would stick around for the current request and subsequent request, and then the controller could get objects from the previous request and determine if it should put them in the new thisRequestAndTheNextOne object for the current request. I don't know if that makes sense to anyone else, but, nevertheless, does anyone have any ideas to do what I'm trying to do? Does anyone else feel my pain? ;) Thanks, -Jeff -- 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]
RE: howto avoid overuse of session object?
try forums.java.sun.com there's a jsp/servlet forum -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 11:14 AM To: [EMAIL PROTECTED] Subject: OT: howto avoid overuse of session object? This is sort of off-topic, but I don't know of a better forum targeting Java web/servlet programming. If anyone does know of one, could you let me know? I'm basically wondering if others have found effective ways to avoid the tempting but bad practice of loading up the session with all sorts of attributes. I often find myself needing some Bean or other object for maybe 2 or 3 requests, and, rack my brains as I may for an elegant way of passing the object along without putting it in the session, I usually end up with nothing more than a headache and 1 more attribute in my session. :( I'm developing with an MVC approach, with Struts for more recently developed apps and a similar custom framework for our older apps, but I just can't seem to see a way to get around this problem. I would love it if there were an object like a thisRequestAndTheNextOne object, where attributes would stick around for the current request and subsequent request, and then the controller could get objects from the previous request and determine if it should put them in the new thisRequestAndTheNextOne object for the current request. I don't know if that makes sense to anyone else, but, nevertheless, does anyone have any ideas to do what I'm trying to do? Does anyone else feel my pain? ;) Thanks, -Jeff -- 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]
Re: howto avoid overuse of session object?
Thanks, Cédric and Peter Lin, for your responses. Both of you seem to be saying that, instead of storing large objects in the session object, I should be storing them in the application object (ServletContext). I find this to be rather confusing. It seems like the overhead involved in storing things in the application object would be much greater than storing things in the session object. At least the session objects would eventually die when sessions time out or they are invalidated by the web app, and the space they were using could then be garbage collected. But the application objects would live as long as the server is up, and I would think would eventually consume memory moreso than using the session would. Also, there would be a extra level of complexity involved with maintaining the association between the objects in the application object and their respective sessions. Am I unclear on the concept, or is there something else that I'm not understanding? Thanks, -Jeff Cédric Viaud cedric.viaud@matraTo: Tomcat Users List [EMAIL PROTECTED] si-tls.fr cc: Subject: Re: howto avoid overuse of session object? 08/01/02 11:30 AM Please respond to Tomcat Users List Hi, FIRST For non-specific Tomcat questions, it exists : [EMAIL PROTECTED] There's also an other one wich is JSP oriented. SECOND All best practice i know says that you must minimize the ammount of data stored in the session. So, the traditional approach of this problem is to only store the user-id (simple type) in the session. All over session informations (a class containing all required informations) are stored in the servlet context. Praticaly, on the request you get the user id from the user session. Next you use this Id to get the user information obect from the servlet context. This is certainly deceiving, but this is the way ... Maybe someone knows better practice ? Regards, Cédric - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 01, 2002 6:13 PM Subject: OT: howto avoid overuse of session object? This is sort of off-topic, but I don't know of a better forum targeting Java web/servlet programming. If anyone does know of one, could you let me know? I'm basically wondering if others have found effective ways to avoid the tempting but bad practice of loading up the session with all sorts of attributes. I often find myself needing some Bean or other object for maybe 2 or 3 requests, and, rack my brains as I may for an elegant way of passing the object along without putting it in the session, I usually end up with nothing more than a headache and 1 more attribute in my session. :( I'm developing with an MVC approach, with Struts for more recently developed apps and a similar custom framework for our older apps, but I just can't seem to see a way to get around this problem. I would love it if there were an object like a thisRequestAndTheNextOne object, where attributes would stick around for the current request and subsequent request, and then the controller could get objects from the previous request and determine if it should put them in the new thisRequestAndTheNextOne object for the current request. I don't know if that makes sense to anyone else, but, nevertheless, does anyone have any ideas to do what I'm trying to do? Does anyone else feel my pain? ;) Thanks, -Jeff -- 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]
Re: howto avoid overuse of session object?
Thanks, Cédric and Peter Lin, for your responses. Both of you seem to be saying that, instead of storing large objects in the session object, I should be storing them in the application object (ServletContext). ServletContext is not application context (yes, there is an application context, too). If you need objects saved between requests, during one session then session has to have enough information to save the state. If you're not going to pack all the state in the current session (I'm not sure why is this a bad idea), then your other option is to pack that some place else and just store some ID in the session. Whether you're packing single beans in hierarchically higher contexts or you place them into a database (via JDBC) or create EJB (an overkill and misuse, I'm sure), you still end up saving that information somewhere. So, somewhere it will fill up memory, buffers, disk, whatever. I cannot fathom why it is better to load piles of objects into higher contexts and have to worry about identifying them and cleaning up after expired sessions, than having them in session context. I find this to be rather confusing. It seems like the overhead involved in storing things in the application object would be much greater than storing things in the session object. Same here. At least the session objects would eventually die when ssions time out or they are invalidated by the web app, and the space they re using could then be garbage collected. But the application objects would live as long as the server is up, and I would think would eventually consume memory moreso than using the session would. You would have to implement session cleanup via some Listener (SessionListener or some such class). Basically, you'd be emulating something like dispersed session context, with parts of a particular session held elsewhere. Ugly, nasty, not to mention slow. IMHO. Also, there would be a extra level of complexity involved with maintaining the association between the objects in the application object and their respective sessions. Am I unclear on the concept, or is there something else that I'm not understanding? Would someone enlighten us. Why is session context so dreadful that we should avoid it? I agree we should minimize it's use, but minimization is not avoiding the use. Nix.
