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

Stefan H. Holek stefan at epy.co.at
Wed Nov 16 06:40:51 EST 2005


Try to partition your collision space. Do you mount a shared temp_folder?
Don't! Do as Chris said and keep a temp_folder per ZEO client. Let the
load balancer send people to the same ZEO client every time (according to
the cookie).

Note that there is no solution for bad coding practice other
than to fix it ;-). Keep session access to an absolute minimum (read *and* write).

You may also want to look at SQLSessions, which seem to be able to take a
higher load (haven't tried for a while). But only up to a point until you
get concurrency issues in the RDBMS. Psycopg in particular defers
conflicts to Zope by again raising ConflictErrors...

In the end, the key to scaling is to keep state out of the app server.

http://www.loudthinking.com/arc/000479.html
http://www.danga.com/words/2004_oscon/oscon2004.pdf

Stefan


On Tue, 15 Nov 2005, Dennis Allison wrote:

>
> Peter,
>
> That's pretty much what we've done, but it is not really enough in
> our case.  Our sites are interactive with lots of per user state.  We make
> fairly heavy use of session variables to track the state.  Our number of
> simultaneous users is also fairly high.  In addition, during development,
> we structured things for ease of development rather than for mimimum
> liklihood of conflict errors.  At this point we are seeing many conflicts
> and interactions with both the sessioning mechanism and the persistence
> mechanism--or so it appears.
>
> Even when we resolve the current database interaction problem, a
> refactoring seems in order to ensure the number of conflicts is kept to a
> minimum.
>



More information about the Zope mailing list