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
