> 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
