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]
