Absolutely. This is too big of a change to force on all framework users
On Jan 18, 2013, at 1:58 PM, "Thiago H de Paula Figueiredo" <thiag...@gmail.com> wrote: > In the end, aren't the correct synchronization approach too specific for each > scenario for a web framework to provide them? The atomicity problem described > in the article is almost only solvable by turning data immutable, the stored > object itself taking care of synchronization or the code that uses the data > doing that (the AtomicReference example). > > Anyway, I think the default value for the symbol that turns on or off the > Tapestry session synchronization feature should be false (disabled). > > On Fri, 18 Jan 2013 17:47:36 -0200, Howard Lewis Ship <hls...@gmail.com> > wrote: > >> Please read http://www.ibm.com/developerworks/library/j-jtp09238/index.html >> >> Because attributes in the HttpSession may be mutable, we acquire an >> exclusive write lock when reading attributes. >> >> Deadlock hell would be the annotation based approach being discussed, where >> there are any number of paths to the point where a lock occurs. >> >> I haven't had a chance to pull up the discussion that led me down this >> path, beyond Brian's article above. I value robustness and thread safety >> above other concerns. >> >> On Fri, Jan 18, 2013 at 6:04 AM, Nelson Rodrigues < >> nel...@nelsonjrodrigues.com> wrote: >> >>> Hello, >>> >>> This to me seems like a one way ticket to deadlock-land. Unless you're >>> able to define a strict lock hierarchy and always acquire locks in the >>> same exact order, this option will be extremely difficult for >>> application developers to use correctly. >>> >>> Just my 2 cents. >>> >>> Cheers, >>> Nelson. >>> >>> >>> >>> On 18/01/2013, at 11:11, Thiago H de Paula Figueiredo >>> <thiag...@gmail.com> wrote: >>> >>> >> Also, I find it much to coarse-grained to either enable it for the >>> whole application or for nothing. >>> > >>> > Agreed too. It seems it's a lock on the whole session (am I right?), >>> something that doesn't make sense at first to me. When two different >>> threads accessing different attributes in the session at the same time, >>> none should be blocked. Why not a lock per session attribute? Or per >>> @Persist field or @SessionState type? >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: dev-h...@tapestry.apache.org > > > -- > Thiago H. de Paula Figueiredo > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
