[Checkins] [zopefoundation/ZEO] 062cbe: If vote fails with a conflict error, invalidate th...

[GitHub]

  Branch: refs/heads/simplify-server-vote-error-handling
  Home:   https://github.com/zopefoundation/ZEO
  Commit: 062cbecc273b58ebbebd26eec1e8abae89795d0d
      https://github.com/zopefoundation/ZEO/commit/062cbecc273b58ebbebd26eec1e8abae89795d0d
  Author: Jim Fulton <jim at zope.com>
  Date:   2016-07-01 (Fri, 01 Jul 2016)

  Changed paths:
    M src/ZEO/ClientStorage.py

  Log Message:
  -----------
  If vote fails with a conflict error, invalidate the corresponding cache entry

This used to happen via the server calling serialnos, but ZEO 5
servers no longer do this.  For the reason for invalidating the cache
entry, see the new comment.


  Commit: 5e6fd05f0ae58eb30179a9ec47c83c5a00bd35d6
      https://github.com/zopefoundation/ZEO/commit/5e6fd05f0ae58eb30179a9ec47c83c5a00bd35d6
  Author: Jim Fulton <jim at zope.com>
  Date:   2016-07-01 (Fri, 01 Jul 2016)

  Changed paths:
    M src/ZEO/cache.py
    M src/ZEO/interfaces.py

  Log Message:
  -----------
  Make the cache thread safe again. :/

There are some cases where we want to touch the cache outside of the
I/O thread. Including:

- ClientStorage wants to to invalidata cache entries if it gets a
  conflict error in voting.

- loadBefore can probably be optimized by checking the cache in the
  client thread. (This will be safe for loadBefore, because the intent
  in practice is never to load current data.


  Commit: 020a9f8c671ff5af253e8924e2f012b9a891164b
      https://github.com/zopefoundation/ZEO/commit/020a9f8c671ff5af253e8924e2f012b9a891164b
  Author: Jim Fulton <jim at zope.com>
  Date:   2016-07-01 (Fri, 01 Jul 2016)

  Changed paths:
    M src/ZEO/StorageServer.py
    M src/ZEO/asyncio/server.py
    M src/ZEO/asyncio/tests.py
    M src/ZEO/tests/forker.py
    M src/ZEO/tests/protocols.test
    M src/ZEO/tests/testZEO2.py

  Log Message:
  -----------
  Simplified error handling during vote

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....


Compare: https://github.com/zopefoundation/ZEO/compare/062cbecc273b^...020a9f8c671f