On Nov 17, 2005, at 4:46 AM, Dennis Allison wrote:
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.
Making the resolution higher has been observed to reduce conflicts
(see dunny's chart).
I have
not dorked with disabling the inband housekeeping. I don't see how it
would impact on our problem. Am I missing something?
Turning off inband housekeeping has the potential to reduce the
numnber of conflicts because less work is done during normal
sessioning operations. Instead of doing the work to figure out
whether it needs to clean up after itself during "normal" operations
it relies on an external process.
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.
I couldn't know one way or another, but if you believe so...
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.
Good idea...
- C
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
_______________________________________________
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 )
