Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.


> 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.

Right. The point is that fallingsquirrel hasn't solved the hard part of the problem.

> If you're specifically talking about the ABA problem, that's trivial to fix with a generation counter.

Maybe, but you need to specify that that's what you're doing, and it may come with undesirable consequences.


> The point is that fallingsquirrel hasn't solved the hard part of the problem.

Sure. My point is that I don't see any issue with the read they described, not that I think there is a solution to partitioning here.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: