[Glass] Why session locking is necessary for Seaside?

[Dale Henrichs via Glass]

On 03/21/2017 12:25 PM, Mariano Martinez Peck via Glass wrote:
> Hi,
>
> I was reading this old post from Dale [1] which explains the topic 
> very nice. After having watched the 
> #seasideProcessRequestWithRetry:resultBlock:  and WASession >> handle: 
>   and the post, I have some questions.
>
> On one paragraph you said:
>
> /"Object locking as a technique for avoiding commit conflicts shares 
> the ‘retry on failure’ model ofWATally, so it isn’t necessarily 
> superior to ‘retry on commit failure’. It is a superior technique, if 
> you need to protect logical updates where a physical conflict cannot 
> be guaranteed (i.e., updates to different portions of an object graph)./
> /"/
>
> *And that's EXACTLY what I was wondering... why the commit failure 
> (conflicts) / abort / retry would NOT be enough for sessions and avoid 
> the lock? *Is that because of that sentence "/ if you need to protect 
> logical updates where a physical conflict cannot be guaranteed" /
> So that's the case for Seaside sessions? It's not safe to update 
> (without conflict) different parts of the session subgraph ?
The primary reason for the Seaside session object lock is that Seaside 
itself had (and presumably still has) a mutex on the session object that 
only allows Pharo-based Seaside to handle one request at a time in a 
single vm.  The session object lock emulates the in-vm mutex semantics 
for multi-gem GemStone and guarantees logical consistency for the 
session state. Unfortunately it is not enough to rely conflicts to 
guarantee logical consistency.

> This is sad, because many many many requests would be read-only to 
> what the session matters (unless there is something obvious I am not 
> seeing?) and in that case, the requests WOULD be able to be 
> parallelized on different Gems.
>
On the other hand, if you know that you have read-only requests, you 
could arrange for a pool of seaside gems to be serving read-only 
requests by putting the gems behind a different ip address, disabling 
the session lock altogether and unconditionally aborting after finishing 
request processing (this is roughly the equivalent of what Johan is 
doing with his pool of REST gems -- I think). I suppose you could embed 
something in the http request itself to tell the server to process a 
read only request as well... that way your entire pool of seaside gems 
could alternate between server session-based requests and session-less 
requests ...
>
> I know Johan recommends session affinity [2] and I understand why. 
> It's just that I would prefer to be able to have multiple requests to 
> the same session in parallel in different gems. At least those that 
> wouldn't fail due to a commit conflict on the session.
>
This does bring up a question that I haven't thought about before:

   How does an Ajax request "bypass" the session mutex in a Pharo-based 
Seaside vm?

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170321/d2c70bcd/attachment.html>