[Seaside] [Glass] Why session locking is necessary for Seaside?

[Johan Brichau]

> On 22 Mar 2017, at 18:50, Dale Henrichs <dale.henrichs at gemtalksystems.com> wrote:
> 
>> That should be the WAMutualExclusionFilter, no?
>> This one is never installed in the Gemstone code.
>> 
> Ah, that does look like the one ... so maybe you know how/if this filter is bypassed by ajax calls when running in Pharo ... or perhaps it's just more visible with GemStone?

It’s installed as a filter on the session. Everytime the session is accessed, the request passes by that mutual exclusion filter.
So: ajax requests are also mutually exclusive in Pharo.

They should be, since ajax requests update the component state as well.

Instead of adding read-only callbacks to Seaside, I’m more in favor of taking a look to make it easier to redirect callbacks to a REST service (Seaside or Zinc) where there is no session to lock by definition.
That’s what we do if needed, but it’s true that it’s all hand-made.

Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20170324/5f84877f/attachment.html>