Or at worst, make it optional, turned off by default. On Jan 14, 2013, at 8:19 AM, Felix Scheffer <fschef...@netzgut.net> wrote:
> How about ReentrantReadWriteLock instead of ReentrantLock. Requests could > read data from the session simultaneously until a request is actually > writing to the session. > > Felix > > 2013/1/14 Howard Lewis Ship <hls...@gmail.com> > >> 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 <denis.stepa...@gmail.com >> <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: dev-unsubscr...@tapestry.apache.org<javascript:;> >>> For additional commands, e-mail: dev-h...@tapestry.apache.org >> <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: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
