It seems that session beans should have synchronized methods to avoid some of these problems?
-----Original Message----- From: simon [mailto:[EMAIL PROTECTED]] 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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
