Thatswhy you normally use a transactional storage for entity beans. Your case is working on the weaknesses of the http protocol which is inherently stateless.
2009/7/14 kristjankelt <kristjank...@hotmail.com> > > 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 > >
