<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>