[Glass] Why session locking is necessary for Seaside?

[Mariano Martinez Peck via Glass]

On Tue, Mar 21, 2017 at 5:57 PM, 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.
>


I wonder if that's still the case on latest Seaside. Do you have a clue
where I can check myself?



> The session object lock emulates the in-vm mutex semantics for multi-gem
> GemStone and guarantees logical consistency for the session state.
>

I am intrigued about the ORIGINAL needs of such a need. Because as Pharo
and GemStone and too it makes me wonder if the lock would be needed on
GemStone.



> Unfortunately it is not enough to rely conflicts to guarantee logical
> consistency.
>

Do you have more details about this? An example maybe?



>
>
> 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 just analyzed this carefully, and I cannot guarantee my requests are
fully read only ahahahahhaha.


> 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?
>
>
Does it?




> Dale
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>


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