On Tue, Jan 15, 2013 at 3:04 PM, Josh Canfield <[email protected]>wrote:
> 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
> if (!lock.isLocked())
> {
> lock.lock();
> }
> }
> lock.lock() is only called if nobody else has the lock, so the method falls
> through and the thread goes about it's business.
>
:) That's hilarious. Here we are, all arguing about how important it is to
go about it this way or that way and we don't even know notice the code
doesn't do anything.
> 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)
>
Yes, an interesting proposal that might work.
Kalle
> 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
> >
>
