• Jim Fulton's avatar
    Simplified error handling during vote · 020a9f8c
    Jim Fulton authored
    ZEO's vote error handling was extremely and weirdly complicated.
    There's a hysterical explanation: Originally, the ZEO protocol was
    synchronous and mirrored the storage API. That was too slow, so store
    was made asynchronous.  But then there was no way to return new
    serials, so we added a serialnos client API that the server called
    during TPC. This was used both to serials and errors.  Later, tpc_vote
    was added, which is a synchronous method. That would have been an
    execllent opportunity to fix this, but noooooooooo.
    
    I'd like the server vote logic to get simpler, and we also want to get rid
    of serialnos, as it makes it hard to commit multiple transactions at
    once on the client.  We can't get rid of serialnos now, because the
    client needs to work with old servers.
    
    Of course, nothing is easy. There was a special edge case where if the
    client saw an unhandled conflict error, it would invalidate it's cache
    for that object, allowing it to eventually recover when caches had
    missed invalidations. This required a change to ClientStorage, which
    meant that the server wouldn't work with older ZEO versions, which
    meant that the server could only support protocol Z5, which in tern
    affected protocol-negotiation tests....
    020a9f8c
protocols.test 4.83 KB