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.
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]
