<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 03/21/2017 02:13 PM, Mariano
Martinez Peck wrote:<br>
</div>
<blockquote
cite="mid:CAA+-=mUbSx3abSVpxqQhQ2uAQYArAdrjWTV1oQ0Un0tH2HCLYw@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<blockquote
cite="mid:CAA+-=mUbSx3abSVpxqQhQ2uAQYArAdrjWTV1oQ0Un0tH2HCLYw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
I've read some of the newer Seaside code and while I can easily tell
that there is still session state being copied and restored (see
senders and implementers of snapShotCopy and restoreFromSnapShot:),
it is not easy to tell how it is being protected from logical or
physical corruption ... WACache has a mutex protecting the cache
updates, but I still don't see how the component snapshots are being
protected from concurrent updates ... <br>
<br>
<blockquote
cite="mid:CAA+-=mUbSx3abSVpxqQhQ2uAQYArAdrjWTV1oQ0Un0tH2HCLYw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
Logical inconsistency occurs in transactions when you use
stale data to make a calculation or produce a report or
update persistent state. For a simple example, let's say
that you look at a persistent count and you use that count
to generate a report. The report will be logically
consistent if the persistent count and the data used to
generate the report are guaranteed to be in the same
transactional view. If you read the persistent count, abort
and then generate the report, you will have a logical
inconsistency if the count changed between the time that you
read the count and generated your report and there will be
no commit conflict to indicate that there is an
inconsistency, because you are reading inconsistent data. <br>
<br>
A persistent logical inconsistency can occur if you update
an object based upon the stale counter value and then commit
... There is no guaranteed commit conflict in this case and
no indication that you've introduced corruption.<br>
<br>
if you use an object lock to protect the counter and the
data used to generate the report, then you can know that
your data is consistent by acquiring the object lock, read
the counter abort, generate your report and release the lock
... <br>
</div>
</div>
</div>
</div>
<blockquote
cite="mid:CAA+-=mUbSx3abSVpxqQhQ2uAQYArAdrjWTV1oQ0Un0tH2HCLYw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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. <br>
</div>
</div>
</div>
</div>
</blockquote>
It's not only the Seaside session state that is being protected from
concurrent updates by the Seaside session lock. Your application
data is also being protected and you don't have to carefully analyze
your code to know whether it is safe or not ...<br>
<br>
I would say that it is theoretically possible to move the
transaction boundaries further down into the Seaside code, but I'm
not so sure that it can be done without radically changing how
Seaside works ...<br>
<br>
It occurs to me that you could still use a pool of REST gems that do
not lock session state as long as you put your own protections in
place ... perhaps objects locks at a finer level of granularity?<br>
<blockquote
cite="mid:CAA+-=mUbSx3abSVpxqQhQ2uAQYArAdrjWTV1oQ0Un0tH2HCLYw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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?<br>
</div>
</div>
</div>
</div>
</blockquote>
If I knew, I wouldn't ask the question:)<br>
<br>
Dale<br>
</body>
</html>