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