Incosistency between PickleCache and Relstorage

Hi there,
I am using Plone 5.1rc1 with Relstorage 2.1.a2 and ZODB-5.2.4.

I found out that after shutting down the MySQL process in the right moment while saving a random content object the change will be written into the PickleCache but not in the Database. Of course I get the error Lost connection to backend server. when doing this but the next time I try to edit the same object I get ValueError: A different object already has the same oid in Module ZODB.Connection, line 610, in _store_objects. After restarting the instance/client it works again and I can edit the object.

Unfortunately I do not quite understand how this whole storing process works but it seems to me that there is an inconsistency between the PickleCache and the Relstorage. I tried to call self._cache.invalidate(oid) and self._cache.minimize() when this happens but it does not seem to work as I thought.

It is not easy to trigger this bug what I think it is. I wrote a little bash script which calls the @@edit-View using wget and with varying delays between 100 ms and 400 ms kills the mysql process.

Why am I doing this? I want to use a GaleraCluster with two or more redundant database servers. If the server Plone is connected to shuts down Plone automatically connects to the next available server. This works good in principle but there is this small time window where it does not work correctly because of the PickleCache I guess. There should be a command which automatically clears the cache if the database server was away or something like this. But I don't know if that would be the correct solution.

I also found this strange TODO in ZODB-5.2.4.py2.7.egg/ZODB/ near line 610:

    self._cache[oid] = obj
    # Dang, I bet it's wrapped:
    # TODO:  Deprecate, then remove, this.
    if hasattr(obj, 'aq_base'):
        self._cache[oid] = obj.aq_base

And just in case you wondering if that bug is new: It also happens with Plone 4.x. I already tested quite a few releases between Plone 4.3 and 5.1, and also with ZODB3 and Relstorage 1.6. And this part of the code was never touched.