Nodes edg-perf[10-13], partition handling on
1.Transaction is started on edg-perf10
2. Value of key_000000000000065B is updated within the transaction
3. Transaction is successfully prepared on edg-perf11 & edg-perf12
4. Transaction commit is issued
5. Other participating nodes (edg-perf11 & edg-perf12) are suspected...
... as they received a new view (without edg-perf10) meanwhile.
Still, the transaction is commited on edg-perf10 & updated entry is stored locally
6. Other nodes rollback the transaction
7. edg-perf10 receives a new view, containing nodes edg-perf[10,11,13]. Incoming state transfer overwrites the updated value
8. get operation returns outdated value
From client perspective, this behavior is not transparent. Provided the transaction ended up successfully, presence of the updated entry can be assumed.