Dennis Allison wrote:

Chris McDonough identified a persistence problem with the routine(s) that manage sessions variables. (Thanks Chris) I have put the correction in place which resolved some (but not all) of the problems.

There are still problems which are apparently due conflicts in accessing
the session variables.  To minimize frequency of conflicts, I am rewriting
several routines using Dieter's rules of the thumb (Thanks Dieter).

One routine being modified is a Script(Python) that initializes a number
of session variables.  I am collecting the session values in a dictionary
and then use update to set their value, for example:

        s = {}
        s['alpha'] = 'a'
        s['beta'] = 'b'

Is the persistence machinery smart enough to detect this as a change?  I
suspect that it has to be flagged since the assignment won't be seen. Usually this means setting the _p_changed=1 attribute, but it is not clear to me where to set it in this particular context.


Did you means request['SESSION']['someDictionary'].update(s)?
Anyway your idea seems correct - The SESSIONS chapter (at least on addresses SESSION "staleness" and mutable objects.

1) someDict = SESSION['someDict']
2) someDict['someKey'] = "newValue"

But (2) does not guarentee that a subsequent lookups like:
SESSION['someDict'] will return "newValue".

But this WILL:
3) SESSION['someDict'] = someDict.

Which looks like your example. How this connect to your primary issue: *conflicts* is not clear to me. :-\


Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to