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

[David H]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zope/attachments/20051219/d079261f/attachment.htm