[ZODB-Dev] StorageServer's waiting list

[Jim Fulton]

On Thu, Nov 12, 2009 at 1:18 AM, Christian Theune <ct at gocept.com> wrote:
> On 11/09/2009 08:06 PM, Jim Fulton wrote:
>>>
>>> [...]
>>>
>>> Z1a will not be able to issue another commit, those are blocked locally
>>> by ClientStorage but pure reading transactions will go through.
>>>
>>> Z1b will be fine because ZEO1 knows about the ongoing commit and puts
>>> Z1b into the waiting list when trying to vote, allowing other reads from
>>> that connection to go through.
>>>
>>> However, when Z2 tries to commit, it starts filling the commit log on
>>> ZEO2. ZEO2 doesn't know about the ongoing commit on the upstream ZEO and
>>> will allow the vote phase to go upstream. However, know the commit from
>>> Z2 gets stuck because it is put in the waiting list on the upstream ZEO
>>> while ZEO2 thinks it was able to proceed.
>>
>> Right, the vote call from ZEO2 blocks until the server is able to complete
>> the in process transaction.
>
> Ok, I think I got it now. So for that (small?) period in time all ZEO
> clients for ZEO2 that cause a vote will also be blocked from any other
> calls for that time.  Whereas ZEO clients from ZEO1 will be able to vote
> but still continue to do other calls, like load.

No. ZEO1 and ZEO2 have the same behavior and, because the current ZEO
implementation is single threaded, all requests to ZEO1 and ZEO2 will
block until their vote calls return.  ZEO1 will be able to handle
other calls
after it's vote call returns. ZEO2 will have to wait longer, since it
has to wait
for the transaction ahead of it to complete.

In ZODB 3.10, ZEO servers will allocate a thread per client. In that
case, both ZEO1 and ZEO2 would be able to handle requests for other
clients while blocking on vote calls.

> So the behaviour of clients of ZEO1 differs a bit from the behaviour of
> clients of ZEO2.

No, at least not with respect to blocking on vote calls.

If either issues a vote call, the vote call will block for some period of time.

...

>> Consider a simpler example. There are 2 ZEO clients, C1 and C2, of a server, S.
>>
>> C1 calls tpc_vote on S (after calling tpc_begin and making some store
>> calls.) It's vote call
>> proceeds because there weren't other transaction committing on S.
>>
>> Now C2 calls tpc_vote. It will block, until C1 calls tpc_finish or
>> tpc_abort.  It is just as
>> blocked as Z2 is in your fan-out example above.
>
> Well, difference being that C2 will still be able to perform other calls
> in parallel over its connection as it's put in the waiting list on S.

Yes, assuming that it is multi-threaded.

> What I'm trying to point out in my above scenario is that ZEO2 will
> block all calls as it's not in the waiting list of ZEO2 but on ZEO.

ZEO1 will block all calls too. This has nothing to do with the waiting
list. It has to do with the fact that ZEO servers are currently single
threaded and therefore can't take advantage of the fact that
ClientStorage has some ability to serve multiple threads.

Jim

-- 
Jim Fulton