> The value is now stale, but it was correct at some point between the read starting and the read finishing, right?
Not necessarily. Maybe both versions of it were from partial writes that were never committed, so your invariants are violated (if we're talking about e.g. a credit account A and debit account B scenario).
> That can happen with any read. Even without any partitions. Can't it?
Depends on your isolation level. If your system has serializable transactions then it's supposed to give you a history equivalent to one where all transactions were executed serially, for example.
> Not necessarily. Maybe both versions of it were from partial writes that were never committed, so your invariants are violated (if we're talking about e.g. a credit account A and debit account B scenario).
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. (Or you could be handling consistency by waiting to see if the transaction succeeds or fails, making sure it would fail if the data you read got backed out. But in that situation nothing goes wrong here.)
> Depends on your isolation level. If your system has serializable transactions then it's supposed to give you a history equivalent to one where all transactions were executed serially, for example.
Even then, a new write can happen before your "read finished" packet arrives at the client, making the read stale. Your entire transaction is now doomed to fail, but you won't know until you try to start committing it.
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'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.
Not necessarily. Maybe both versions of it were from partial writes that were never committed, so your invariants are violated (if we're talking about e.g. a credit account A and debit account B scenario).
> That can happen with any read. Even without any partitions. Can't it?
Depends on your isolation level. If your system has serializable transactions then it's supposed to give you a history equivalent to one where all transactions were executed serially, for example.