Operating System: All
Platform: All

I can see two obvious ways to approach this problem:

1.) Expose a notion of logical time explicitly so that applications can ask if they are the owner of X at logical time t. Then when they go to do something, they can say, assuming logical time is <= t do this.

2.) Expose the notion of logical time implicitly through a test-and-set method, e.g., assuming the value of leaf Y is Z at the shard leader, then do this.

Because the only things we currently provide strong ordering over are data store operations, this will only apply to data store operations. (Apparently in YANG 1.1, you order notifications and and RPCs with respect to data operations, so that will likely come later.)

In effect, both 1.) and 2.) would have to do the same thing, which is to send a transaction to the leader where the leader can check if logical time is <= t or if leaf Y is Z and then either process the transaction or fail it.

This would at least give the correct behavior which is that an application wouldn't be able to accidentally take actions while it erroneously believed it was the leader. It has the disadvantage of involving an interaction with the leader of the shard storing the entity ownership state every time you want to do something that assumes you are the owner of a given entity.

You can fix some of that by issuing leases on ownership of entities and promising not to violate those leases even if the owner becomes inactive. You need to be careful to account for clock skew and drift when deciding if a lease is still active though.

Linking bugs which are essentially feature requests on the EOS API.

The other thing we need to think through is how this interacts with shards.

A logical call to "assuming I'm the owner for entity X, do Y" would likely need to first go to the shard leader for the entity ownership shard and then be forwarded to the shard leader(s) for the various edits to Y. As long as call calls corresponded to the same pair of shards (call them shard(X) and shard(Y))

I think this would work assuming that the logic at the leader for shard(X) made sure to keep the ordering between incoming conditional writes and outgoing unconditional writes.

The fundamental problem here is that this API implies that it provides mutual exclusion, but that is meaningless without a definition of time. Most people would assume that the time would be wall-clock time, but this API clearly does not provide mutual exclusion over wall-clock time.

Instead, if we want this to provide mutual exclusion, we need to adopt a definition of (logical) time for which it provides mutual exclusion.

I will try to drive the API definition done by M4.

The fix for BUG-5414 makes it less likely that you violate mutual exclusion as defined by wall-clock time, but it's still possible.