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
