<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 21, 2017 at 5:57 PM, Dale Henrichs via Glass <span dir="ltr"><<a href="mailto:glass@lists.gemtalksystems.com" target="_blank">glass@lists.gemtalksystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<p><br>
</p>
<br>
<div class="m_-2929974016077522591moz-cite-prefix">On 03/21/2017 12:25 PM, Mariano
Martinez Peck via Glass wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>I was reading this old post from Dale [1] which explains
the topic very nice. After having watched the
#<wbr>seasideProcessRequestWithRetry<wbr>:resultBlock: and WASession
>> handle: and the post, I have some questions. </div>
<div><br>
</div>
<div>On one paragraph you said:</div>
<div><br>
</div>
<div><i>"<span style="color:rgb(84,84,84);font-family:verdana,helvetica,arial,sans-serif;font-size:12.16px">Object
locking as a technique for avoiding commit conflicts
shares the ‘retry on failure’ model of</span><span style="color:rgb(84,84,84);font-family:verdana,helvetica,arial,sans-serif;font-size:12.16px"> </span><span style="color:rgb(84,84,84);font-family:verdana,helvetica,arial,sans-serif;font-size:12.16px">WATally</span><span style="color:rgb(84,84,84);font-family:verdana,helvetica,arial,sans-serif;font-size:12.16px">,
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).</span></i></div>
<div><i>"</i></div>
<div><br>
</div>
<div><b>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? </b>Is that because
of that sentence "<i><span style="color:rgb(84,84,84);font-family:verdana,helvetica,arial,sans-serif;font-size:12.16px"> if
you need to protect logical updates where a physical
conflict cannot be guaranteed" </span></i></div>
So that's the case for Seaside sessions? It's not safe to update
(without conflict) different parts of the session subgraph ?</div>
</blockquote></span>
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. </div></blockquote><div><br></div><div><br></div><div>I wonder if that's still the case on latest Seaside. Do you have a clue where I can check myself?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"> The session object lock emulates the in-vm
mutex semantics for multi-gem GemStone and guarantees logical
consistency for the session state.</div></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"> Unfortunately it is not enough to
rely conflicts to guarantee logical consistency.</div></blockquote><div><br></div><div>Do you have more details about this? An example maybe? </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>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. </div>
<div>
<div><br>
</div>
</div>
</div>
</blockquote></span>
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 ... <br><span class="">
<blockquote type="cite">
<div dir="ltr">
<div>
<div><br></div></div></div></blockquote></span></div></blockquote><div><br></div><div>I just analyzed this carefully, and I cannot guarantee my requests are fully read only ahahahahhaha. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div dir="ltr"><div><div>
</div>
<div>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. </div>
<div><br>
</div>
</div>
</div>
</blockquote></span>
This does bring up a question that I haven't thought about before: <br>
<br>
How does an Ajax request "bypass" the session mutex in a
Pharo-based Seaside vm?<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></div></blockquote><div><br></div><div>Does it?</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="HOEnZb"><font color="#888888">
Dale<br>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Glass mailing list<br>
<a href="mailto:Glass@lists.gemtalksystems.com">Glass@lists.gemtalksystems.com</a><br>
<a href="http://lists.gemtalksystems.com/mailman/listinfo/glass" rel="noreferrer" target="_blank">http://lists.gemtalksystems.<wbr>com/mailman/listinfo/glass</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br></div>
</div></div>