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. > _______________________________________________ Zope maillist - Zope@zope.org 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 )