Now that Eza supports multi-key updates, it needs to ensure that these "transactions" never stop on each other mid-processing. If two transactions touch the same keys, then they must happen entirely separately and one after the other.
In other words, implement the (I)solation of ACID.
It may be useful to add a user-visible first-class Transaction entity. The order of these incoming transactions needs to be determined before they can be processed.
A simple approach to start with may be to have each transaction lock the keys they do any of their writes.
Now that Eza supports multi-key updates, it needs to ensure that these "transactions" never stop on each other mid-processing. If two transactions touch the same keys, then they must happen entirely separately and one after the other.
In other words, implement the (I)solation of ACID.
It may be useful to add a user-visible first-class Transaction entity. The order of these incoming transactions needs to be determined before they can be processed.
A simple approach to start with may be to have each transaction lock the keys they do any of their writes.