[Glass] Why session locking is necessary for Seaside?

[Mariano Martinez Peck via Glass]

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.


Do you have more advice on this topic besides the one I already got on the
mailing lists?

Thank you very much.


[1] https://gemstonesoup.wordpress.com/2008/03/17/glass-101-fire/
[2]
http://jbrichau.github.io/blog/when-to-use-http-session-affinity-in-glass


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