Sorry, it looked like discussion is over and it will stay this way. Denis
Jan 15, 2013 v 1:41 PM, Taha Siddiqi <tawus.tapes...@gmail.com>: > Hi Denis > > You have made your point and everybody agrees with you but your tone has not > been polite. > > regards > Taha > > On Jan 15, 2013, at 6:02 PM, Denis Stepanov wrote: > >> Howard, it is so selfish to assume that everyone's apps should have requests >> processed in the sequential order. Only argument you have is that someone >> wants it, if you are just going to ignore this issue it will show a bad >> leadership, you are not the only one who is using Tapestry. >> >> Use locking per-case, only if you need it without forcing everyone into it, >> specially not with an exclusive session access. >> >> Denis >> >> Jan 14, 2013 v 5:29 PM, Lenny Primak <lpri...@hope.nyc.ny.us>: >> >>> 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 >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: dev-h...@tapestry.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
