Nice one
On 26 Feb 2004, at 17:27, Craig R. McClanahan wrote:
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:
app. I wouldGiven 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 mythe sessionalso do what you said in a previous post - which is "clean up"to use thestuff when they navigate away to another part of the app.
I'm in the "do it in request unless you have good reason(s)transfersession" 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
toMy application has an Asset search form. The user can enter many criteriasearch on.form
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 searchuntil 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 Iinputs onall of the details I want to display about that person in hiddenchange then I'dthe form. If the details I want to display about a Personbeans. Anytoalso need to change the hidden fields. In addition once I ship the applicationofmy customers they may have their own JSP developer show extra prpoertiesthe selected Person.
So, that's my justification for using session scoped form-------------------------------------------------------------------- -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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
