[ZODB-Dev] [ZEO] rather long periods of unresponsiveness

[Dieter Maurer]

Jeremy Hylton wrote at 2004-12-19 01:24 -0500:

Thank you very much for your quick response!

> ...
>Note that the long delay at vote may also be a problem because it is a
>synchronous call.  The client will block waiting for vote to return,
>regardless of whether the server runs it in another thread.  The
>blocking could be unfortunate if another thread in the same app server
>wants to load an object; the load will be blocked until the vote
>finishes, even if the server could be responsive.

For us, it is no immediate problem: we use dedicated ZEO clients
for large transactions. Our primary problem is that the cluster
monitor kills ZEO when it is not responsive enough.

>We looked at changing vote to be asynchronous about a year ago.  There
>may even be a branch with a partial implementation of the feature,
>although I've got no recollection of the branch's name.  It might be
>good to consider both changes, although the asynchronous vote is a
>protocol change and probably more delicate than the threading change.

This sounds good -- for general ZEO clients...

When we are at it: the "CommitLog" trick in ZEO
reduces the time during which ZEO does not accept
"commit" requests from different (!) ZEO clients.
Each individual client still prevents multiple connections
to start overlapping commits. In my example case, commits
were blocked (in a single ZEO client) for about 7 min.
Would the connection pass an id to "tpc_begin", "store" and
friends (e.g. the transaction id) and the
ClientStorage pass it on, then the "CommitLog" could be
maintained per id -- eliminating long term "commit" blackouts...

-- 
Dieter