> I suppose the framework could keep a Mutex keyed on session so that > multiple page or event requests could be serialized on the server. Actually I think it is a great idea, and a pretty clean solution... thats the way Spring resolves it, its certainly not a hack. Since you create a session once it should not be such a big deal at all: http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/web/util/HttpSessionMutexListener.html
> I am loathe to have the framework manage this automatically because it > causes its own problems. > For example, it is reasonable to process multiple Ajax requests in > parallel if they only read data. Other than a flag that the framework will have to manage, I really don't see it being such a big deal... maybe I am naive and missing something, but do you think it is better for Tapestry users to manage this? having Atomic references and Synchronized blocks all over our code, it is easy to miss something when dealing with thread safety, and what of performance? Peter ----- Original Message ----- From: "Howard Lewis Ship" <hls...@gmail.com> To: "Tapestry users" <users@tapestry.apache.org> Sent: Tuesday, 14 July, 2009 22:08:04 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: T5 Page field persistance and multithread problems On Tue, Jul 14, 2009 at 3:10 AM, kristjankelt<kristjank...@hotmail.com> wrote: > > 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. I suppose the framework could keep a Mutex keyed on session so that multiple page or event requests could be serialized on the server. I am loathe to have the framework manage this automatically because it causes its own problems. For example, it is reasonable to process multiple Ajax requests in parallel if they only read data. >> >> 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 > > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos --------------------------------------------------------------------- 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
