The performance is not the only issue with bloated sessions.... Like in our current project, we are using WSAD4.0 and websphere does nto guareentee that session will be transferred across in a clustered environment if the session size is more than 4k..And we are having our depoyment in a clustered environment with 200% (??:-))) failsafety against downtime etc etc...
There are other issues like you are never clear which data you are working with..And even for other sites with a fairly large amount of traffic, session size must be critical when it comes to performance eventhough i must admit that I have never worked on such web project. But the workflow solution is for situations when you dont want to use session scope But still want to share data across screens And also manage Modal dialogue boxes in a wizard liek flow.So there is no point in discussing the pros and cons of it in situations where session size is not an issue..Even in that case i will refrain from using session scoped form beans...U are never sure which set of data you are working with...:-(( -----Original Message----- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, February 12, 2004 4:54 PM To: Struts Users Mailing List Subject: Re: [OT] - Request against Session On 12 Feb 2004, at 15:44, Andrew Hill wrote: > <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? I agree, java does the job nicely but if you're gonna get your knickers in a twist about using sessions and you've got time to burn then a c cgi would probably out perform a java solution (assuming you don't write shit that is). > > <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. Also agreed, but i've been working with java/jsp for about 5 years now and been lucky enough to work as a web tier person on for some high profile sites. And frankly all this session paranoia is disportionate to the actual problems that occur using httpsession. Perhaps your experiences have been different, but surely expecting web developers not to use session is just complete nonsense especially during the development stage rather than bug fixing stage. You'd be more likely to loose the contract by not delivering the project in the first place, though irrational session avoidance. > > 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] > --------------------------------------------------------------------- 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]
