I had a lot of experiences with users using multiple tabs of the same browser. They can do really a mess
p.stavrini...@albourne.com ha scritto: >> Multiple threads accessing the same data concurrently => potential >> threading issues. >> > > Yes its true that multiple requests can occur when referencing a session, so > technically there is a thread safety design flaw in the Servlet spec, but an > HttpSession is tied to a particular user and browser session, which reduces > the likelihood, though they can still happen. Serializing requests on an > HttpSession can remove most of these concurrency problems by serialized > invocations from the same client, but again its not that likely, where there > is a larger issue is unsafe access to the ServletContext. > > Peter > > > > > > > > ----- Original Message ----- > From: "Robert Zeigler" <robe...@scazdl.org> > To: "Tapestry users" <users@tapestry.apache.org> > Sent: Tuesday, 14 July, 2009 17:03:22 GMT +02:00 Athens, Beirut, Bucharest, > Istanbul > Subject: Re: T5 Page field persistance and multithread problems > > Alfie, actually, many people have done just that. > And for the record, Kristjan is right in that this is very much a > threading issue. > Multiple threads accessing the same data concurrently => potential > threading issues. > In the case of non-persisted field and values on a page, you don't > have threading issues because the data is unique to each request. But > the moment you introduce session-persisted data, you've moved beyond > that scope and you absolutely have to consider multi-threaded > effects. The problem is marginal for @Persisted fields; at least the > persisted-data is specified to a single page. But using session state > objects, the potential problem becomes worse. If you're using session > state objects, and you're not considering the impact of multiple > threads on your data, you're asking for trouble. That said, this > problem is certainly not unique to Tapestry; anytime the session is > invoked, you have potential threading issues. > > Cheers, > > Robert > > On Jul 14, 2009, at 7/148:09 AM , Alfie Kirkpatrick wrote: > > >> Hi Kristjan, >> >> I think your mail is interesting but tend to agree with the other >> posters who say this is not a Tapestry issue per se. I do not know of >> any framework that queues up requests from a particular session to >> ensure they are not executed in parallel. This would seem to be a bad >> idea in principle. >> >> Given that read/writes to the session itself are not synchronised, >> it is >> always possible for multiple request threads to get invalid state from >> the session. >> >> A potentially valid point is that the Tapestry model makes this >> 'worse' >> by automatically reflecting the session at the start of processing and >> only writing it back at the end (assuming this is what it does -- can >> anyone confirm?). In a lower-level framework like raw servlets you >> could >> potentially minimise the effect of this problem by re-reading the >> session value before writing it back after a long running process, but >> you'd still have to deal with the exception if it had changed >> (assuming >> your long running process made use of the old value somehow!). Even in >> this extreme case you'd only be minimising the problem because another >> thread could still read and update the session state while you are >> doing >> the same at the end of your processing. >> >> Perhaps there is already a standard pattern in Tapestry to avoid >> multiple submits of a form? Although this would not affect your test >> as >> you have multiple browser windows. >> >> Hope this makes sense, >> Alfie. >> >> -----Original Message----- >> From: kristjankelt [mailto:kristjank...@hotmail.com] >> Sent: 14 July 2009 11:11 >> To: users@tapestry.apache.org >> Subject: Re: T5 Page field persistance and multithread problems >> >> >> Hi, >> >> >> Peter Stavrinides wrote: >> >>> Kristjan, as Nille has explained to you that is simply not the case, >>> >> what >> >>> is happening is multiple requests are being generated when the submit >>> button is clicked more than once, each of these Requests spawns a new >>> thread, and triggers the events that modify the affected values >>> accordingly. >>> >>> Persisted objects scoped to 'session' are essentially just objects >>> >> placed >> >>> in the HttpSession, which is perfectly thread safe to do, so what >>> >> thread >> >>> problems are you referring to? >>> >>> >> Multiple threads (initiated by multiple requests) accessing the same >> data is >> definitelly thread issue - it does not go away when you say that >> this is >> multiple request issue instead and everyone else is having the same >> problem. >> >> Of course this problem is caused by multiple requests that are allowed >> to >> run in paralel when they should wait in the queue instead but stating >> this >> does not make the code thread safe. >> >> And of course this is really simple example that does not involve any >> data >> sent by the client - that would introduce more problems. >> >> >> Peter Stavrinides wrote: >> >>>> every page instance would have it's own *copy* of the data >>>> >>> Although a page object itself is pooled, and a clean copy is served >>> >> when >> >>> its requested. That does not mean that it contains copies of state >>> >> objects >> >>> / data, if you peek inside the users HttpSession you will find only a >>> single SSO (or persistent field for that matter) of any session >>> scoped >>> objects. So far as I understand there are no 'copies' of these >>> objects >>> >> or >> >>> any other session data floating around, any persistent object in your >>> >> page >> >>> would simply be a 'reference' to those in the HttpSession. >>> >>> >> Let say that I have new request. What happens now is that page is >> taken >> from >> the pool and is initiated. >> >> During that variable is read from the session and reference of the >> page >> object private variable is set to that variable. >> >> Let assume that there was object Integer(1) in the session. Now both, >> session and page object private variable are referencing to the same >> object. >> Let's name this variable a counter. >> >> Let say that in the page event method (like in my example) I want to >> increment the counter. For that I read the object Integer(1) int >> (primitive) >> value (or this is done by compiler using autoboxing), add one to it >> and >> create new object Integer(2) and set page private variable reference >> to >> new >> object (Object(2)) (this happens because Integer is immutable and I >> can >> not >> change it's innerstate). >> >> >>> From this moment, page and session will have different copies (and it >>> >> will >> stay so until session reference is overridden at the end of page >> processing). >> >> When different thread is reading from the session then it will still >> see >> the >> reference to Integer(1) and it's corrensponding page object private >> variable >> reference is set to Integer(1). >> >> Now this example involved only one variable and this was immutable >> (you >> can >> not change it's innerstate). Having multiple variables or immutable >> variables (like entity beans) will introduce more problems. >> >> Regards, >> Kristjan Kelt >> -- >> View this message in context: >> http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems >> -tp24468298p24476799.html >> Sent from the Tapestry - User mailing list archive at Nabble.com. >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > -- ================================================== dott. Ivano Mario Luberti Archimede Informatica societa' cooperativa a r. l. Sede Operativa Via Gereschi 36 - 56126- Pisa tel.: +39-050- 580959 tel/fax: +39-050-9711344 web: www.archicoop.it ================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
