[Zope] conflicts, sessions, and programming best practices guidelines

[Chris McDonough]

Changing the architecture will likely get you the most bang but note  
also that there are a few knobs that you can turn on the transient  
object container UI that may limit the number of conflicts (in the  
temp_folder/session_data_container):

- "Data object timeout value" -- the timeout value in minutes.. make  
this higher.

- "Timeout resolution" -- the timeout resolution in seconds.. make  
this higher.

You can also turn off "inband housekeeping" of session data by  
calling the method "disableInbandHousekeeping" on a transient object  
container.  At that point, sessions will continue to work properly  
but "old" session data won't be garbage collected and you will need  
to do this every so often by calling the "housekeep" method on  TOC.

See this written by dunny about conflicts and sessions (although this  
was written before MVCC):

http://www.plope.com/Members/dunny/conflicts/view

HTH,

- C


On Nov 16, 2005, at 6:18 PM, Dennis Allison wrote:

>
> Chris,
>
> I am aware that using ZEO to back session database is likely to  
> increase
> the opportunity for conflicts, but using a single session database  
> seems
> to be reaquired if you want, as we do, to distribute out interactive
> application acrosss a cluster of processors cleanly.
>
> Under our current approach, we have multiple Zopes running on multiple
> machines, all referencing a shared database of session variables.
> This allows a HTTP request to be blindly distributed to any of the
> machines.  Given the conflict problems, we may need to rethink this
> simplistic architecture.
>
>
> On Tue, 15 Nov 2005, Chris McDonough wrote:
>
>>
>> On Nov 15, 2005, at 5:54 PM, Dennis Allison wrote:
>>
>>>
>>> Has anyone prepared a set of best practice guidelines on the
>>> techniques to
>>> use to minimize conflicts?
>>>
>>> It is becoming clear that we need to do to refactor some of our
>>> code to
>>> get us out of our current conflict pickle.
>>>
>>> A quick google produced lots of commentary but nothing I could hand
>>> to our
>>> programmers as guidelines.
>>
>> Nothing in general except the (probably too general) "attempt not to
>> allow one process/thread to write to the same object at the same time
>> as another process/thread".
>>
>> One tip, since you've told us you use sessions heavily: using ZEO to
>> back your session database provides more opportunity for conflicts
>> than if you used a "normal" Zope storage.  This is because:
>>
>> - the opportunity for conflict naturally grows as transaction time
>> increases and using a ZEO storage rather than a local storage adds
>> latency to the total transaction time that would not otherwise exist.
>>
>> - you have "n" processes attempting to write to essentially the same
>> objects at the same time when you use a shared ZEO sessioning
>> database.  If these were instead local databases, each process would
>> only compete "with itself" (between all of its threads).
>>
>> I tend to try to use local sessioning databases backed by tempstorage
>> plus a frontend load balancer that allows for cookie-based session
>> affinity (Pound).
>>
>> - C
>>
>
> -- 
>
>
>