<snip> Surely if performance is that much of an issue then java would be the last technology you'd use. </snip>
What would you suggest for a high performing web application? <snip> If there are performance issue with this and you haven't abused the use of session then IMO this is a matter for the container developers. </snip> Not much help when you have to fix a performance issue for a customer within 24 hours or lose a huge contract. That said, if you havent abused the session your very unlikely to get such performance issues unless it really is a container bug (time to switch containers). Of course what counts as abuse very much depends on your expected load (and things like whether you need to cluster). Whats abuse for a public portal with 1000 hits per second is just fine for an intranet app thats unlikely to have more than a dozen simultaneous hits... -----Original Message----- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, 12 February 2004 22:14 To: Struts Users Mailing List Subject: Re: [OT] - Request against Session While I found your solution interesting. But whether the session is "bloated" or not is other folk's problem. The javadoc for HttpSession says what its for, the other way is to persist out-side of the web tier which is another subject. Sure you don't want to use session for everything that would be silly, but its also there to be used. Its simply a matter of mind-set, if you want to get down to the metal then I'm not sure java is an ideal technology. From a web developer's pov you read the docs you see that httpsession is for certain situations and thus you use it. If there are performance issue with this and you haven't abused the use of session then IMO this is a matter for the container developers. Surely if performance is that much of an issue then java would be the last technology you'd use. On 12 Feb 2004, at 14:49, <[EMAIL PROTECTED]> wrote: > The whole point is there is no concept of a Workflow scope in Servlet > API and if you want to share objects , you have to put them in > session.And then clearing them is not always easy, as you will never > be clear when user may leave the workflow scope.And you have to code > for it in every action. > > What this extension does is to leave all those details to framwrork, > and the programmer just has to COnfigure the actions ,saying that they > belong to a workflow.And then he has no more worries as to getting a > bloated session, as the session gets trimmed of workflow objects as > soon as user goes to any screen which is not part of work flow. > > HTH. > regards, > Shirish > > -----Original Message----- > From: Robert Nocera [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 12, 2004 2:36 PM > To: 'Struts Users Mailing List' > Subject: RE: [OT] - Request against Session > > > > This is probably even more off topic, but I've seen this mentioned > before. > From what I can tell of their description of this "workflow" scope, it > looks > like it may be helpful as far as ease of use goes, but it doesn't > offer any > real technical benefit over the use of hidden form fields or sessions, > in > fact, the underlying implementation has to be something passing > parameters > of using the session, there just isn't any alternative in any compliant > application servers. > > As far as the objects being cleared when the user leaves the workflow, > how > is that any different the using the session correctly? If the user > goes on > to another page that is not part of your current "workflow" you can > clear > those objects or you wait until the user's session times out -- those > are > really the only two options. > > -Rob > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > Sent: Thursday, February 12, 2004 4:21 AM > To: [EMAIL PROTECTED] > Subject: RE: [OT] - Request against Session > > Hi Guys, > I think the issue over here is, in such cases we need a new > scope(workflow > scope).The existing scopes(request/session) do not suffice in such > cases. > > ... > The session scope can be used but it may not be cleared.So there has > to be a > solution at architecture level.And the struts workflow extension > http://www.livinglogic.de/Struts/introduction.html > ... > > > --------------------------------------------------------------------- > 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]
