Chris, thanks again. You've clarified several issues. Interlinear comments below, original text edited with a heavy hand for brevity... On Wed, 21 Dec 2005, Chris McDonough wrote:
If this is the same getSessionVariable as you reported before (a Python Script), note that each call that you make to it has overhead. It might be better to create a single Python script to return all of the values that you need from the session rather than calling this over and over again. If that doesn't work, it might be even better to just do SESSION.get('foobar') instead of calling a Python Script for every value.
Good point. No overhead is probably the right thing especially since there are no subtransactions.
I still don't have an intuitve understanding of the conflict mechanism in practice. For example, Why is the conflict error reported for the navigation dtml method rather than for the getSessionVariable python script which actually references the SESSION object where the conflict occurs?
Write conflicts happen for a transaction. In Zope, there is one transaction per request. So it reports the URL of the method that was called as the thing that caused the conflict (because, basically, it was). A conflict is not "noticed" until a transaction is committed; ZODB has no idea what caused the data structure to change in a conflicting way within "application code".
Ah so desu. That's the conceptual hook I was missing. Only one transaction per request and no subtransactions! A transaction is processing initiated by a client request or a redirect. (Anything else?) A transaction has its own REQUEST and RESPONSE objects.
A conflict error gets raised whenever another thread references the same session's SESSION object.
Are you using frames by any chance? It would be understandable that you're seeing an increased number conflicts if you have an application in which many threads try to access the same session object at once due to a browser making multiple writes to the same session object because of frames.
Yes, we do use frames. We manage rendering explicitly with a bit of Javascript magic so the full frameset rarely gets rerendered. But, it certainly could be a contributing factor.
Apparently the MVCC read-read conflict resolution fails for session variables although I am not sure why.
Can we see one of the conflict tracebacks? You should be seeing only write conflicts. Read conflict errors are reported in a traceback with a ReadConflictError message (conflicts reported as only ConflictError are write conflicts).
I'll try to find a few tracebacks. --