[Seaside] [Glass] Why session locking is necessary for Seaside?
johan at inceptive.be
Fri Mar 24 18:58:18 UTC 2017
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside