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 <[email protected]>: > >> Or at worst, make it optional, turned off by default. >> >> On Jan 14, 2013, at 8:19 AM, Felix Scheffer <[email protected]> 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 <[email protected]> >>> >>>> 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] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
