You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Erich Meier <em...@methodpark.de> on 2002/02/06 15:46:44 UTC
Problem: multiple browsers and session state
Hi!
Are there any best practices known, how to deal with a user accessing a
struts application with multiple browsers at the same time?
Because cookies are shared between browser instances, these browsers run within
the same session - this is also true when cookies are blocked and URL session
identifiers are used.
This corrupts the session state - i.e. an action in one browser influences
the next action done in the other browser.
Is there any simple solution for this? I mean other than keeping all your state
in hidden HTML form fields, which would render the session concept rather
useless?
Thanks in advance,
Erich
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem: multiple browsers and session state
Posted by simon <si...@zerosoftware.net>.
>
> Unfortunately, this does not solve my "multiple browsers in single
session"
> problem.
>
Being pragamatic, I don't actually think you can solve this insofar as come
up with a one-size-fits all fix for these kind of issues.
.s
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem: multiple browsers and session state
Posted by Erich Meier <em...@methodpark.de>.
On Wed, Feb 06, 2002 at 03:02:15PM -0000, simon wrote:
> This is application-independant, in that it's not just struts this affects
Correct.
> One solution is to look for potential collisions and implement a lease/lock
> strategy on the resources that my collide (similar to std. file/resource
> locking), although with a lease on the lock due to the stateless nature of
> the app. in question.
Hmm, but what to do with true session data like a "current project" or "current
view" bean. This could also be placed into a form as hidden data, but why should
I use the session scope at all then?
> When I've had problems where multiple users edit the same data, I've
> generally taken the easy option and decided that the users have to have at
> least an iota of sense and collaberate with each other.
This is also our strategy: users should cooperate, last update wins, business
logic must assert consistency of its data.
Unfortunately, this does not solve my "multiple browsers in single session"
problem.
Erich
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem: multiple browsers and session state
Posted by Greg Hess <gh...@wrappedapps.com>.
It seems that session beans should have synchronized methods to avoid some
of these problems?
-----Original Message-----
From: simon [mailto:simon@zerosoftware.net]
Sent: Wednesday, February 06, 2002 10:02 AM
To: Struts Users Mailing List
Subject: Re: Problem: multiple browsers and session state
This is application-independant, in that it's not just struts this affects
One solution is to look for potential collisions and implement a lease/lock
strategy on the resources that my collide (similar to std. file/resource
locking), although with a lease on the lock due to the stateless nature of
the app. in question.
When I've had problems where multiple users edit the same data, I've
generally taken the easy option and decided that the users have to have at
least an iota of sense and collaberate with each other.
.s
----- Original Message -----
From: "Erich Meier" <em...@methodpark.de>
To: <st...@jakarta.apache.org>
Sent: Wednesday, February 06, 2002 2:46 PM
Subject: Problem: multiple browsers and session state
> Hi!
>
> Are there any best practices known, how to deal with a user accessing a
> struts application with multiple browsers at the same time?
> Because cookies are shared between browser instances, these browsers run
within
> the same session - this is also true when cookies are blocked and URL
session
> identifiers are used.
>
> This corrupts the session state - i.e. an action in one browser influences
> the next action done in the other browser.
>
> Is there any simple solution for this? I mean other than keeping all your
state
> in hidden HTML form fields, which would render the session concept rather
> useless?
>
> Thanks in advance,
> Erich
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem: multiple browsers and session state
Posted by simon <si...@zerosoftware.net>.
This is application-independant, in that it's not just struts this affects
One solution is to look for potential collisions and implement a lease/lock
strategy on the resources that my collide (similar to std. file/resource
locking), although with a lease on the lock due to the stateless nature of
the app. in question.
When I've had problems where multiple users edit the same data, I've
generally taken the easy option and decided that the users have to have at
least an iota of sense and collaberate with each other.
.s
----- Original Message -----
From: "Erich Meier" <em...@methodpark.de>
To: <st...@jakarta.apache.org>
Sent: Wednesday, February 06, 2002 2:46 PM
Subject: Problem: multiple browsers and session state
> Hi!
>
> Are there any best practices known, how to deal with a user accessing a
> struts application with multiple browsers at the same time?
> Because cookies are shared between browser instances, these browsers run
within
> the same session - this is also true when cookies are blocked and URL
session
> identifiers are used.
>
> This corrupts the session state - i.e. an action in one browser influences
> the next action done in the other browser.
>
> Is there any simple solution for this? I mean other than keeping all your
state
> in hidden HTML form fields, which would render the session concept rather
> useless?
>
> Thanks in advance,
> Erich
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>