Has anyone had time to measure differences between before and after performance?
I know it's not that easy at all but maybe it's worth a try... On Wed, Jan 16, 2013 at 3:00 AM, Howard Lewis Ship <[email protected]> wrote: > 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 > <[email protected]>wrote: > > > 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 > > > > > > > > > > > > > -- > 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 > -- Massimo http://meridio.blogspot.com
