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: [email protected] For additional commands, e-mail: [email protected]
