On Sun, Jan 13, 2013 at 4:54 PM, Howard Lewis Ship <[email protected]> wrote:
> And I've had equal discussion from others demanding this feature, so there > you go. > This is an open source project. Can you link to those discussions or refer to them otherwise here? I agree with Denis, a long running request can create major performance issues with this in place. I especially don't like the idea that read access is locked for the whole lifetime of a request. I'm not too worried for myself as I can just replace this implementation with my own but really, making this the default seems potentially quite problematic for the new users. Kalle On Sunday, January 13, 2013, Lenny Primak wrote: > > > Howard, is there a particular use case for this? This sounds like an > > overkill and unnecessary. > > There are also most likely locking going on just to get to the per thread > > access to the field even before the session gets accessed. > > I view is change as a performance killer as well with no benefits > > whatsoever. > > > > Good catch Denis. > > > > On Jan 13, 2013, at 5:57 AM, Denis Stepanov <[email protected] > <javascript:;>> > > wrote: > > > > > Changes introduced in > https://issues.apache.org/jira/browse/TAP5-2049bring some bad > consequences. > > > > > > Now, if your request accesses the session every other request will wait > > to access the session until the previous request is done, it means long > > running request could block all other requests, this bring major > > performance issues. > > > > > > Some points I have mentioned in the comments: > > > > > > - We have many concurrent ajax request, this change means major > > performance issue for us! > > > - This will not work in a clustered environment, the clustered session > > class shouldn't inherit the locks functionality. > > > - Tapestry should not do this by default, any kind of synchronization > > between the requests is bad idea and should be avoided at any cost. > > > > > > Cases when you need to synchronize session's state should be dealt with > > individually, not forcing everyone into using it. > > > > > > Tapestry should not try to outsmart the servlet specification, the > > session object should only be wrapping the HttpSession without bringing > > some major behavior changes. Session synchronization is anti-pattern and > > should not be promoted in a first place. > > > > > > Denis > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected]<javascript:;> > > For additional commands, e-mail: [email protected] > <javascript:;> > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com >
