On Sun, Jan 13, 2013 at 7:46 PM, Lenny Primak <[email protected]>wrote:
> Perhaps a few more details are in order? Is this for SSOs, @Perstst > objects? > Sounds like a crutch. > If this has to do with per thread objects wouldn't those be already locked > anyway? > Again, it's an open source project. There's no point discussing this if you don't bother taking a look at the code. https://github.com/apache/tapestry-5/blob/master/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/SessionImpl.java Kalle > > > On Jan 13, 2013, at 6:54 PM, Howard Lewis Ship <[email protected]> wrote: > > > And I've had equal discussion from others demanding this feature, so > there > > you go. > > > > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
