On 16 Feb 2004, at 17:25, Niall Pemberton wrote:
Sorry if I'm regurgitating, but I haven't really been following this debate.
The only good argument I've heard for session=evil is the memory bloat one.
But thats a good reason not to use java at all. I've one's got that much of a cob-on about ram usage then don't use java. If its that much of a problem then better hitting the disk than filling memory (the later being how java manages to perform at all).
If every struts form was defined in session scope then a user running around
alot of forms can quickly consume alot - and it stays around unless you
specifically clean them out or they do nothing long enough for the session
to expire. Whether you have memory problems depends entirely on the amount
your stuffing into the session and the number of 'active' sessions at any
one time.
I think the suggestion was sometimes copying request scoped forms into a session is a reasonable thing, certainly during the development cycle, rather than optimizing before anything is built. Sure always using session would be silly but nobody has said that. But never using session is arguably equally ludicrous.
The good thing about doing everything in request scope is you never have to
worry about this - however big your system or the traffic volume gets. In
that sense its a no-brainer - tell everyone to do it in request and theres
no consequences. If the advice on the other hand was session or request -
you choose - alot of people would choose session because its easier to
develop - once they deploy the app though, then the <grin>s**t hits the
fan</grin>.
When you deploy to a dev server thats probably a good time to address any problems.
If you know the memory implications and the future traffic volumes of your
system and can guarantee its never going to be an issue, then go ahead. For
me though, even though it looks like I'm only going to have 20-40 users
initially, I do it the request way - because then I don't even have to
consider it as an issue, whatever the future.
Niall
----- Original Message ----- From: "Mark Lowe" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Monday, February 16, 2004 3:41 PM Subject: Re: [OT] - Request against Session
Ah.. I'm having a bad hibernate day instead today so I'm a bit more distracted from this debate.
Truth is I'm pretty stupid, my simplistic way of looking at the world tells me that if i need to temporally store data collected from some forms that storing in the session is a way to do this.
The api says. "The session persists for a specified time period, across more than one connection or page request from the user."
Seems to fit the bill to me. Each form is a request and i need a
structure in the web tier to store the data. Until such a time when the
user is ready to complete whatever s/he is doing and thus commit
everything to the model.
I even concede I'm out-gunned in terms of the folk advocating such
things, but I just cant see why everyone's so against sessions. I'm in
crisis attempting to resolve the incongruity between my and folk's, who
know better than me, views, but I just don't get it.
But when did sessions become the root of all evil? What are they there
for? I even like the idea of dynamically generating hidden values as an
alternative or an optimization but surely session is a valid tool to
use.
Perhaps my understanding of data-mining is erroneous but I fail to see how storing data collected via a view (in the web tier) for a short time has anything to do with it.
"Data mining is the process of discovering meaningful new
correlations, patterns and trends by sifting through large amounts of
data stored in repositories, using pattern recognition technologies as
well as statistical and mathematical techniques." (Gartner Group).
Another definition I found is
"Data Mining follows an inductive strategy of analyzing data where users apply machine learning algorithms to gain non-obvious knowledge from the data." [http://www.jcp.org/en/jsr/detail?id=073]
I'm not suggesting any such thing, I'm not forming any analysis on the
data collected and stored in httpsession as that would be silly. Nor do
i see that the proposed alternative as having anything to do with
datamining.
While I can see how a high traffic site need an alternative to
httpsession the storing data collected from the view temporarily before
its ready to be permanently stored (What i understand of what Andrew
has been saying, and I think craig's recommendations). I cant see how
the syllogism "all use of httpsession is bad" can be justified.
Not on all fours but purring like a kitten :o)
Mark
On 16 Feb 2004, at 15:56, Michael McGrady wrote:
You [Mark Lowe] said: Perhaps HttpSession is a blunt instrument, and would need to besubstituted by another persistence >mechanism like say writing to a temporary text file, but IMO this would be something that one >would want to fix in the case that something were broken.
Hi, Mark,
Your reading "generating dynamic views" as somehow relating to alternative forms of persistence is not correct. The idea is to get AWAY from this PERSISTENCE solution and to start using view LOGIC.
Michael
java language was in part an >attempt to abstract software developmentAnd you [Mark Lowe] said: i know its a naive position but I thought part of the scope of the
from the hardware.
Yes. But you are misreading completely what I said. I have no idea how you got to here from what I said. I was doing the opposite, viz. trying to get you to deal with an API for the logic of your views. This has nothing remotely to do with persistent mechanisms or hardware. I suspect we are two ships passing in the night here.
You [Mark Lowe] said:
Okay agreed that generating hidden fields would be a reasonable meansof persistence. Yes I was >assuming, perhaps in error, that what was being suggested was writing hidden fields. In fact I think >I may do this. Also agreed that if the webforms dont have a load of in the jsp then fine and dandy
Generating hidden fields has nothing to do with a "means of
persistence". Rather, this is merely a way to generate hidden fields
relating to the logic of the view, e.g. if you come from one page, you
hidden fields will be one thing, but if you come from another page,
your hidden fields will be another thing. Your use of the session
object is not really a persistence mechanism, Mark. It is a shotgun
data mining technique for the view. The suggestion is to substitute a
scalpel data mining technique for the shotgun.
We more on all fours now?
Michael McGrady
--------------------------------------------------------------------- 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]
