[Glass] Why session locking is necessary for Seaside?

[Kjell Godo via Glass]

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?
>From the stone soup article i got the impression that
     not using the Rc Classes
     was some kind of stop gap sub par way out
Is this not the case?
Why wouldn't you just use the Rc Classes and be done
     with it?
Oh right there are some caviates
     some Rc rules that have to be followed
     They don't seem very restrictive
          and if you violate them once in a blue moon
          then you would just get a retry?
My idea i got from what i read is
     just use the Rc Classes
     problem solved
Is this not the case?
It's because Seaside has no Rc Classes?
Well where are the Rc Classes then

So what i think I'm hearing is
     you can have gemstone gems
     and Seaside gems
     and the Seaside gems don't have the Reduced conflict Classes

or something

please correct me if I'm wrong



On Tue, Mar 21, 2017 at 13:57 Dale Henrichs via Glass <
glass at lists.gemtalksystems.com> wrote:

>
>
> 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 of WATally, 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
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170321/227838cd/attachment-0001.html>