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
>

Reply via email to