Re: [Zope] Re: [Zope-dev] Re: sessions in the presence of conflicts
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Re: [Zope-dev] Re: sessions in the presence of conflicts
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 ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: [Zope-dev] Re: sessions in the presence of conflicts
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
--
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope] 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.
--
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: [Zope-dev] Re: sessions in the presence of conflicts
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
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: [Zope-dev] Re: sessions in the presence of conflicts
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
--
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: [Zope-dev] Re: sessions in the presence of conflicts
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
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
