Locking in the session is a step back. With ajax enabled apps you want to
be able to get these requests to run concurrently. If you're storing your
login token in the session you've now degraded user perception of
performance by making the panels load synchronously.
I believe there could be a need for blocking at a more granular level.
Perhaps Tapestry could provide a way to do that.
Also, I may be missing something, but this doesn't look like it ever blocks
anything
private void lock()
{
if (!lock.isLocked())
{
// The HttpSession may be shared across threads, but the
lock (almost) certainly is.
lock.lock();
perthreadManager.addThreadCleanupCallback(new Runnable()
{
public void run()
{
lock.unlock();
}
});
}
}
lock.lock() is only called if nobody else has the lock, so the method falls
through and the thread goes about it's business.
I recall something about clustering being mentioned in the thread. By
default Tapestry uses the ClusteredSessionImpl (
https://issues.apache.org/jira/browse/TAP5-1489), which doesn't appear to
have been updated with locking (it *REALLY* makes no sense to try to do
this across a cluster).
from TapestryModule
configuration.add(SymbolConstants.CLUSTERED_SESSIONS, true);
Perhaps with specific use cases the community could come up with a good
model for how to handle concurrency-sensitive session attributes?
@Persist(concurrent=false)
Josh
On Sun, Jan 13, 2013 at 4:54 PM, Howard Lewis Ship <[email protected]> wrote:
> 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
>
