Re: [Zope-dev] Re: sessions in the presence of conflicts
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' request['SESSION'].update(s) 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. --
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' request['SESSION'].update(s)
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.
Dennis, Did you means request['SESSION']['someDictionary'].update(s)? Anyway your idea seems correct - The SESSIONS chapter (at least on plope.com) 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. :-\ David
The interaction between sessions, conflicts, and persistence is a bit confusing. I am still trying to understand the code in depth. One thing is for sure, request.SESSION and/or request['SESSION'] must be persistent for things to work. Mutable objects in the session variable set (dictionaries and lists) have to be handled specially to get the persistence machinery to recognize they have been changed. In this case, I am trying to ensure that the session variables get identified as persistent. My question is whether using update (an implicit assignment) triggers the persistence mechanism. It is the moral equivalent of writing request['SESSION']['alpha'] = 'a'B request['SESSION']['beta'] = 'b' but I am unsure whether the persistence mechanism will recognize it as such. Doing session variable initialization in a Script(Python) object has a downside because one cannot set a _p_changed attribute and so must rely on the assignment paradigm. Perhaps the interface should be in a Product or External Method which is less constrained. Anyhow, David, thanks for the assist. On Mon, 19 Dec 2005, David H wrote:
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' request['SESSION'].update(s)
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.
Dennis,
Did you means request['SESSION']['someDictionary'].update(s)? Anyway your idea seems correct - The SESSIONS chapter (at least on plope.com) 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. :-\
David
--
Dennis Allison wrote:
The interaction between sessions, conflicts, and persistence is a bit confusing. I am still trying to understand the code in depth.
One thing is for sure, request.SESSION and/or request['SESSION'] must be persistent for things to work. Mutable objects in the session variable set (dictionaries and lists) have to be handled specially to get the persistence machinery to recognize they have been changed.
In this case, I am trying to ensure that the session variables get identified as persistent. My question is whether using update (an implicit assignment) triggers the persistence mechanism. It is the moral equivalent of writing
request['SESSION']['alpha'] = 'a'B request['SESSION']['beta'] = 'b'
but I am unsure whether the persistence mechanism will recognize it as such.
Doing session variable initialization in a Script(Python) object has a downside because one cannot set a _p_changed attribute and so must rely on the assignment paradigm. Perhaps the interface should be in a Product or External Method which is less constrained.
Anyhow, David, thanks for the assist.
On Mon, 19 Dec 2005, David H wrote:
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' request['SESSION'].update(s)
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.
Dennis,
Did you means request['SESSION']['someDictionary'].update(s)? Anyway your idea seems correct - The SESSIONS chapter (at least on plope.com) 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. :-\
David
Dennis, Lets just put the question out there: Does: SESSION['someKey'] = someValue Force a commited transaction? As opposed to ... someDict = Session['SomeKey'] someDict['aKey'] = 'aNewValue' David David
Trimmed Zope-dev from this (cross-posts are bad)...
Dennis, Lets just put the question out there: Does:
SESSION['someKey'] = someValue
Force a commited transaction?
As opposed to ... someDict = Session['SomeKey'] someDict['aKey'] = 'aNewValue'
Neither "forces a committed transaction", but the former directly marks an object (the session object) as changed. The latter does not mark any object as changed if someDict is actually a Python dictionary and not a first-class persistent object. At the end of a transaction, only objects that are marked as changed are re-persisted to the database. This is further explained in the "mutable subobjects" section of the sessions chapter of the Zope Book on plope.com. - C
On Dec 20, 2005, at 12:36 AM, Dennis Allison wrote:
The interaction between sessions, conflicts, and persistence is a bit confusing. I am still trying to understand the code in depth.
One thing is for sure, request.SESSION and/or request['SESSION'] must be persistent for things to work. Mutable objects in the session variable set (dictionaries and lists) have to be handled specially to get the persistence machinery to recognize they have been changed.
In this case, I am trying to ensure that the session variables get identified as persistent. My question is whether using update (an implicit assignment) triggers the persistence mechanism. It is the moral equivalent of writing
request['SESSION']['alpha'] = 'a'B request['SESSION']['beta'] = 'b'
but I am unsure whether the persistence mechanism will recognize it as such.
The implementation of TransientObjects's update method is: def update(self, d): self._p_changed = 1 for k in d.keys(): self[k] = d[k] So yes... - C
participants (3)
-
Chris McDonough -
David H -
Dennis Allison