Quoting Mark Lowe <[EMAIL PROTECTED]>: > sure i agree .. but I've been wanting to dick around with alternatives > to storing in the session for a while (since the request vs session > debate). and just wondered if anyone had tried read/writing to a flat > file as an alternative. >
Just remember that it's needless extra work and overhead unless the memory occupancy actually matters. The number of "actually matters" applications is likely to be a fairly small percentage of the total. > Additionally I think that sessions are stored in this way anyway so > might be a waste of time. That depends on your container, and how you have it configured. Tomcat, for example, by default only puts sessions in memory unless you're shutting down the app (or the server), in which case it serializes all the session objects to disk. However, you can configure the "PersistentManager" if you wish, which includes the ability to swap active but idle sessions out to disk (either flat files or to a database) in a manner similar to what operating systems do with active but idle processes. From the developer perspective, the nice thing about this is it's zero extra code -- other than the need to make your session objects Serializable, which is not typically very difficult. > But then I imagine that session objects are > loaded into memory where using an old school read-write to a flat file > might be less greedy. > Doing any I-O at all has overhead costs ... if memory is not an issue any such approach is *guaranteed* to make your application slower than leaving the objects in memory. > guess its dog food time. > Buying RAM is cheaper than paying for developer and testing time :-). So is configuring servers if they support the feature already. Craig McClanahan > On 26 Feb 2004, at 15:42, Paul McCulloch wrote: > > > My intuitive response would be that I'd use ram freely and let the O/S > > worry > > about paging stuff to disk if it runs out of physical memory. I'd > > *guess* > > that the O/S can use disk for paging significantly faster than a Java > > programmer can via the JVM & the O/S. > > > > I think that you'd have to run some pretty exhaustive tests in an > > environment close to your production one to determine which method is > > more > > efficient. > > > > Personally I'd just spend the money on a bit more ram instead of > > developer > > time... > > > > Paul > > > >> -----Original Message----- > >> From: Mark Lowe [mailto:[EMAIL PROTECTED] > >> Sent: 26 February 2004 13:24 > >> To: Struts Users Mailing List > >> Subject: Re: need help converting from session to request scope > >> > >> > >> Niall > >> > >> Any opinions on read and writing to flat files to avoid > >> additional ram > >> use? Or you reckon that the reading and writing would consume similar > >> amounts of ram? I'll get around to trying it when i get a moment. > >> > >> On 26 Feb 2004, at 14:04, Niall Pemberton wrote: > >> > >>> Given your scenario, it sounds like a good candidate for a session > >>> scoped > >>> form. > >>> > >>> I agree with what Mark Lowe said - usually/often "...theres no more > >>> work > >>> invloved scoping to request" - thats been the case for my > >> app. I would > >>> also > >>> do what you said in a previous post - which is "clean up" > >> the session > >>> stuff > >>> when they navigate away to another part of the app. > >>> > >>> I'm in the "do it in request unless you have good reason(s) > >> to use the > >>> session" camp - rather than the "anti-session" camp as it may have > >>> appeared > >>> in previous threads. > >>> > >>> Niall > >>> > >>> ----- Original Message ----- > >>> From: "Paul McCulloch" <[EMAIL PROTECTED]> > >>> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > >>> Sent: Wednesday, February 25, 2004 4:13 PM > >>> Subject: RE: need help converting from session to request scope > >>> > >>> > >>>> My application has an Asset search form. The user can enter many > >>>> criteria > >>> to > >>>> search on. > >>>> > >>>> Most of these criteria themselves are looked up from the database > >>>> (e.g the > >>>> Person associated with the Asset search). When the user selects a > >>>> search > >>>> criteria (e.g. the Person) I store the DTO for that person on my > >>>> search > >>>> form. The view element displays details about that Person on the > >>>> search > >>> form > >>>> until the search form is cleared. > >>>> > >>>> Many requests will be made to find the criteria before the Asset > >>>> search > >>>> itself is performed. > >>>> > >>>> To do this using a request scope form would require that I > >> transfer > >>>> all of > >>>> the details I want to display about that person in hidden > >> inputs on > >>>> the > >>>> form. If the details I want to display about a Person > >> change then I'd > >>>> also > >>>> need to change the hidden fields. In addition once I ship the > >>>> application > >>> to > >>>> my customers they may have their own JSP developer show extra > >>>> prpoerties > >>> of > >>>> the selected Person. > >>>> > >>>> So, that's my justification for using session scoped form > >> beans. Any > >>>> comments gratefully recieved. > >>>> > >>>> Paul > >>> > >>> > >>> > >>> > >> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > ************************************** > > Axios Email Confidentiality Footer > > Privileged/Confidential Information may be contained in this message. > > If you are not the addressee indicated in this message (or responsible > > for delivery of the message to such person), you may not copy or > > deliver this message to anyone. In such case, you should destroy this > > message, and notify us immediately. If you or your employer does not > > consent to Internet email messages of this kind, please advise us > > immediately. Opinions, conclusions and other information expressed in > > this message are not given or endorsed by my Company or employer > > unless otherwise indicated by an authorised representative independent > > of this message. > > WARNING: > > While Axios Systems Ltd takes steps to prevent computer viruses from > > being transmitted via electronic mail attachments we cannot guarantee > > that attachments do not contain computer virus code. You are > > therefore strongly advised to undertake anti virus checks prior to > > accessing the attachment to this electronic mail. Axios Systems Ltd > > grants no warranties regarding performance use or quality of any > > attachment and undertakes no liability for loss or damage howsoever > > caused. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
