It's still in transit; and yes, that was supposed to be
isLockedByCurrentThread() (or whatever that method name is).

On Tue, Jan 15, 2013 at 3:19 PM, Kalle Korhonen
<kalle.o.korho...@gmail.com>wrote:

> On Tue, Jan 15, 2013 at 3:04 PM, Josh Canfield <joshcanfi...@gmail.com
> >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 <hls...@gmail.com>
> > 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 <
> denis.stepa...@gmail.com
> > > <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: dev-unsubscr...@tapestry.apache.org
> > <javascript:;>
> > > > For additional commands, e-mail: dev-h...@tapestry.apache.org
> > > <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
> > >
> >
>



-- 
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