struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mainguy, Mike" <>
Subject RE: [OT] - Request against Session
Date Mon, 16 Feb 2004 16:05:22 GMT
Just to throw a little liquid (gasoline or water) on this fire...

Let's say there are two ways to look at determining your current session
#1 Is the Deterministic Automaton (for any set of inputs there is an output)
#2 Is the Nondeterministic Automaton (for any set of inputs the output is

Some, if not many, applications can have the user interface abstracted as a
If this is the case, you can simply pass a series of tokens (the inputs) to
which page you SHOULD be on.  In these cases, passing hidden fields is an
desirable way of doing business (lends to clustering, no dead sessions
hanging around,

On the other hand, other types of interfaces don't lend themselves to this
of doing business: (i.e. they are dependant on internal or unknown factors
determine what to do/display).  In these cases, may or may not need a
session to 
determine where you are/where you are going to maintain the proper
flow/state of 
the application.



-----Original Message-----
From: Mark Lowe [] 
Sent: Monday, February 16, 2004 10:42 AM
To: Struts Users Mailing List
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 

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."

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 

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)


On 16 Feb 2004, at 15:56, Michael McGrady wrote:

> >You [Mark Lowe] said:
> >Perhaps HttpSession is a blunt instrument, and would need to be
> substituted 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
> >And you [Mark Lowe] said:
> >i know its a naive position but I thought part of the scope of the
> java language was in part an >attempt to abstract software development
> 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 means
> of 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

This message and its contents (to include attachments) are the property of Kmart Corporation
(Kmart) and may contain confidential and proprietary information. You are hereby notified
that any disclosure, copying, or distribution of this message, or the taking of any action
based on information contained herein is strictly prohibited. Unauthorized use of information
contained herein may subject you to civil and criminal prosecution and penalties. If you are
not the intended recipient, you should delete this message immediately.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message