Why session locking is necessary for Seaside?

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 ?

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.  

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. 

On Tue, Mar 21, 2017 at 5:57 PM, Dale Henrichs via Glass <[hidden email]> 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?