continuing with my refactorings, I think I might have found additional failure
scenarios that could happen with deserialization + multi transactions.
first failure scenario:
MultiTxn creates two nodes, serialization sees only the first node but not the
second. The zxid of the deserialized DataTree however is set to the MultiTxn,
because deserialization saw the first created node and its zxid.
second failure scenario:
FileTxnSnapLog.restore contains a code block handling a NODEEXISTS failure
during deserialization. The problem is explained there in a code comment. The
code block however is only executed for a CREATE txn, not for a multiTxn
containing a CREATE.
second failure scenario extended:
Even if the mentioned code block would also be executed for multi
transactions, it needs adaption for multi transactions. What, if after the
first failed transaction in a multi txn during deserialization, there would be
subsequent transactions in the same multi that would also have failed?
We don't know, since the first failed transaction hides the information about
the remaining transactions.
Thomas Koch, http://www.koch.ro