[Zope-dev] Re: sessions in the presence of conflicts

[Dennis Allison]

Zope 2.8.4, ZODB 3.4.2

Chris,

I'm pretty sure that I mentioned having done that in one of my postings.
I have followed your recommendations, but the problem remains. (um... 
persists <grin>)

The systems are running a Zope/ZEO combination with a store configuration 
of:

# 
 <zodb_db temporary>
     # Temporary storage database (for sessions)
     <temporarystorage>
       name temporary storage for sessioning
     </temporarystorage>
     mount-point /temp_folder
     container-class Products.TemporaryFolder.TemporaryContainer
 </zodb_db>
# 
# ZEO client storage:
#
<zodb_db main>
  mount-point /
  # ZODB cache, in number of objects
  cache-size 5000
  <zeoclient>
    server 192.168.0.92:8301
    storage 1
    var $INSTANCE/var
    # ZEO client cache, in bytes
    cache-size 20MB
    # Uncomment to have a persistent disk cache
    client group1-zeo
  </zeoclient>
</zodb_db>
#

Although the connection to ZEO is via a network port, it runs on the same 
physical hardware.

TemporaryStorage is not transactional.  Does it need to be under MVCC?  

TemporaryStorage does provide a conflict cache to do "rudimentary conflict
resolution".  There are several timing and scaling parameters that need to
be considered:

CONFLICT_CACHE_MAXAGE = 60  (seconds)
CONFLICT_CACHE_GCEVERY = 60 (seconds)
RECENTLY_GC_OIDS_LEN = 200

Entries in the recently gc's oids list are those which may be resolvable
by a retry.

These numbers may be too small given the loads we see and the number of 
accesses made to the session variables.  I plan to incrase them to see
if there is any impact.


MAYBE CONFLICTS AND THEIR RESOLUTION ARE NOT THE ROOT CAUSE OF THE SESSION
VARIABLE PROBLEM.  The observed problem is that session variables suddenly
disappear.  At the point of failure due to a KeyError, inspecting the 
SESSION object shows two failure modes:  either all the session variables 
are gone and only the container remains or most of the session variables 
are gone and a few remain.

74769573A2H7SIH2AKo=id: 11343269231636975299, token: 74769573A2H7SIH2AKo, 
contents keys: ['currentTab', 'calendarPage', 'currentCourse', 
'currentTextbook']

and 

77307574A2HTTdXCYYg=id: 11343267811075063138, token: 77307574A2HTTdXCYYg, 
contents keys: []

Access to the session variables are almost alwsys through a pair of 
Scripts(Python).  Occasionally a session variable is read with an 
expression of the form REQUEST['SESSION']['key'].

## Script (Python) "getSessionVariable"
##bind container=container
##bind context=context
##bind namespace=
##bind script=script
##bind subpath=traverse_subpath
##parameters=varname
##title=
##
request=container.REQUEST
session=request['SESSION']
return session[varname]

# Script (Python) "setSessionVariable"
##bind container=container
##bind context=context
##bind namespace=
##bind script=script
##bind subpath=traverse_subpath
##parameters=var, val
##title=
##
request = container.REQUEST
RESPONSE =  request.RESPONSE
session=request['SESSION']
session[var]=val
request.set( 'SESSION', session )

This all seems right to me.  Any suggestions as to how to localized when 
the session variables get lost?  That might help localize the root cause.