Thank Chris, good pointsB. The session variable timeout is currently several hours as requird by our application. The timeout resolution remains at its default value. I have not dorked with disabling the inband housekeeping. I don't see how it would impact on our problem. Am I missing something?
I suppose I could do a custom p_resolveConflict since the vast majority of conflicts are are non-conflicting and actual conflicts are fairly easy to identify. Still, on the whole, I think we have to refactor our programs to minimize the opportunities for conflicts as well as tuning the mechanism. As a temporary workaround, I'm backing out of the shared temporary storage in favor of a local temp storage. That should make things a bit better. On Wed, 16 Nov 2005, Chris McDonough wrote: > 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 > >> > > > > -- > > > > > > > -- _______________________________________________ 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 )