On Sun, Jan 13, 2013 at 10:46 PM, Lenny Primak <[email protected]>wrote:
> Oh I read the code. It's about the other parts of request processing that > make session lock unnecessary in all but most esoteric cases. > I see, sorry my mistake then. Kalle > On Jan 13, 2013, at 10:17 PM, Kalle Korhonen <[email protected]> > wrote: > > > 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 g > >>> 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] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
