During node crash, two concurrent modifications in can both succeed in pessimistic transactional cache.

This would cause an inconsistent change of an entry. There is a small timeframe where this can happen as the first transactions must start before the node crash and commit after a successful rebalancing.

1. TX1 originating on node A acquires lock for key X, node A is primary owner
2. node C is killed and node B becomes primary owner of key X
3. TX2 originating on node B acquires lock for key X, node B is (now) primary owner
4. TX1 commits the tx, prepare-Tx is sent with the new topology id so it commits fine
5. TX2 also commits the transaction