Re: [Glass] Why session locking is necessary for Seaside?
Johan Brichau <[email protected]>
| Newsgroups | gmane.comp.lang.smalltalk.squeak.seaside |
|---|---|
| Message-ID | <[email protected]> |
> On 22 Mar 2017, at 18:50, Dale Henrichs <[email protected]> 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 _______________________________________________ seaside mailing list [email protected] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside