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
Note that there is no solution for bad coding practice other
than to fix it ;-). Keep session access to an absolute minimum (read *and*
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.
On Tue, 15 Nov 2005, Dennis Allison wrote:
> 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
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -