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

Mon, 19 Dec 2005 21:59:21 -0800

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  -  [email protected]
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 )

Reply via email to