[Glass] Why session locking is necessary for Seaside?

[Dale Henrichs via Glass]

To expand upon Martin's answer, there _are_ rc collections used for 
collections that can be updated by multiple sessions ... I'm not sure it 
is practical to rewrite all of the Seaside session state code, to 
convert it all to rc collections ... last time I looked there was quite 
a bit of object copying going on so that the old session state can be 
restored based on the which session is involved, so it may not even be 
possible to rewrite Seaside using rc collections ... of course, this is 
all of the detail of logical session state that the session mutex aims 
to protect ...

Dale

On 03/21/2017 02:46 PM, Martin McClure via Glass wrote:
> On 03/21/2017 02:35 PM, Kjell Godo via Glass wrote:
>> What about the Rc... Classes?
>> Why are they not mentioned here?
>> The reducedConflict Classes?
>> I thought the reduced conflict Classes were
>>       the preferred way to reduce conflicts?
> A very short, but I hope helpful, answer:
>
> The RC classes allow you to do things that are physical conflicts
> (concurrent operations modify the same object) but are not logical
> conflicts (in practice, both operations can complete in either order
> with the same result).
>
> This thread, If I'm recalling correctly from a few posts back, is more
> concerned with detecting and preventing logical conflicts (things that
> if done concurrently *would* mess things up) that are *not* physical
> conflicts (no single object is modified by the conflicting operations).
>
> Regards,
>
> -Martin
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass