> I'm pretty sure the scenario above is looking at committed writes.
> If you're reading uncommitted writes, you're not really in the market for consistency to being with.
But what does "committed" mean when you're only reading from one partition in a partitioned scenario? You literally can't tell whether what you're reading is committed or not (or rather, you have to build your own protocol for when a write is considered committed).
> For pure read operations, I'm not convinced it's a proper stale read unless the value was stale before the read operation started.
I think you can get a read that is half from a prior stale operation and half from a subsequent uncommitted operation, or something on those lines.
> But what does "committed" mean when you're only reading from one partition in a partitioned scenario?
I would say you can't make new commits in that situation? I don't know, I didn't make up the scenario, I think you need to figure out your own answer and/or get clarification from fallingsquirrel if you want to talk about that kind of problem.
> I think you can get a read that is half from a prior stale operation and half from a subsequent uncommitted operation, or something on those lines.
What's the full timeline for that?
If you're specifically talking about the ABA problem, that's trivial to fix with a generation counter.
> If you're reading uncommitted writes, you're not really in the market for consistency to being with.
But what does "committed" mean when you're only reading from one partition in a partitioned scenario? You literally can't tell whether what you're reading is committed or not (or rather, you have to build your own protocol for when a write is considered committed).
> For pure read operations, I'm not convinced it's a proper stale read unless the value was stale before the read operation started.
I think you can get a read that is half from a prior stale operation and half from a subsequent uncommitted operation, or something on those lines.