Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

50 years later, is two-phase locking the best we can do?

concurrencyfreaks.blogspot.com

Post reply on HN
Print view View original

51–60 of 87 posts

Re: 50 years later, is two-phase locking the best we can do?

#51

Post by rusk »

bawolff wrote: post #50
nine_k wrote: post #40

Earlier quoted context omitted.

If business software practices is not enough of a proof, look at any massive online games. They all use one central server as a source of truth about the game world, and broadcast that state to the clients. Anything a client reports that diverges from the central server view is either corrected, rejected, or becomes a reason to disconnect the client for cheating attempts. If you need strict order, that order should h…

Bitcoin: Am I joke to you? Everyone: yes.

Bitcoin is an interesting exception to the above. Issue is latency.

Re: 50 years later, is two-phase locking the best we can do?

#52

Post by stevenhuang »

djha-skin wrote: post #31

We are so arrogant sometimes. The passage of time has nothing to do with reality. People seem to think that given enough time and energy and ingenuity we can do anything we want. This is not how the real world works. Sometimes, we find a good solution, and it's the best possible one and we found it early on. We think we can do better, but we can't. A classic example of this is Euclid's fifth axiom. It wasn't proven u…

An excellent illustration of how a lack of diversity in thinking can hinder forward progress. Thank God everyone doesn't think the same as you.

I think it's a testament to the human condition there are those of us willing to entertain the folly of pushing the boundaries, or of being foolish as you put it.

Re: 50 years later, is two-phase locking the best we can do?

#53

Post by mjan22640 »

rawgabbit wrote: post #36
samsquire wrote: post #35

I'm a beginner in this topic and I find this topic interesting. I really want there to be an easy-to-deploy consistency solution. If I have a distributed microservice architecture and I want to keep multiple datastores in synchronization or "consistent" what's the industry best practice? A few days ago I was trying to solve the inconsistency problem with "settled timestamps" which is a kind of multiversioning idea ex…

For distributed systems, the main idea is a centralized write ordering journal that is replayed by individual nodes. Multiple systems write sequentially to the central journal. The journal is simply taking requests like a key value store. The journal is replicated to all the nodes. The nodes read from the journal and performs the complex logic requested.

that is server/many clients, not distributed

Re: 50 years later, is two-phase locking the best we can do?

#54

Post by patrulek »

bigstrat2003 wrote: post #33
djha-skin wrote: post #31

We are so arrogant sometimes. The passage of time has nothing to do with reality. People seem to think that given enough time and energy and ingenuity we can do anything we want. This is not how the real world works. Sometimes, we find a good solution, and it's the best possible one and we found it early on. We think we can do better, but we can't. A classic example of this is Euclid's fifth axiom. It wasn't proven u…

It seems to me that while it's foolish to assume we can always improve on something, it's not at all foolish to try to do better (even if the attempts don't succeed). Asking "can we do better than this?" and trying to find a better way is a prerequisite for progress, after all.

And trying to improve something will often result in improving ourselves (by learning).

Re: 50 years later, is two-phase locking the best we can do?

#55

Post by theptip »

samsquire wrote: post #35

I'm a beginner in this topic and I find this topic interesting. I really want there to be an easy-to-deploy consistency solution. If I have a distributed microservice architecture and I want to keep multiple datastores in synchronization or "consistent" what's the industry best practice? A few days ago I was trying to solve the inconsistency problem with "settled timestamps" which is a kind of multiversioning idea ex…

Look at the Raft protocol. In general you’d rather not integrate at the protocol layer; it’s standard to use a consistent store like etcd that implements Raft for the coordination/data that needs to be serializable.

(Kubernetes uses etcd so it scales pretty well for a strongly-consistent k/v store.)

You said “multiple datastores” so I’m assuming you have heterogenous data and something like CockroachDB isn’t an option.

> I'm a beginner in this topic and I find this topic interesting.

Not trying to gatekeepe but rolling your own is dangerous. See https://aphyr.com/ for the gold standard in testing (great educational material). You can use Jepsen to test your distributed systems. But better to just use datastores that Kyle has shown are solid.

Re: 50 years later, is two-phase locking the best we can do?

#56

Post by rcxdude »

bawolff wrote: post #50
nine_k wrote: post #40

Earlier quoted context omitted.

If business software practices is not enough of a proof, look at any massive online games. They all use one central server as a source of truth about the game world, and broadcast that state to the clients. Anything a client reports that diverges from the central server view is either corrected, rejected, or becomes a reason to disconnect the client for cheating attempts. If you need strict order, that order should h…

Bitcoin: Am I joke to you? Everyone: yes.

There's no performance gain from bitcoin's approach though. The distributed consensus is there for trustless operation, not performance. It's many orders of magnitude slower (and a few more orders of magnitude more power inefficient!) than just having one server handle it.

Re: 50 years later, is two-phase locking the best we can do?

#58

Post by samsquire »

theptip wrote: post #55
samsquire wrote: post #35

I'm a beginner in this topic and I find this topic interesting. I really want there to be an easy-to-deploy consistency solution. If I have a distributed microservice architecture and I want to keep multiple datastores in synchronization or "consistent" what's the industry best practice? A few days ago I was trying to solve the inconsistency problem with "settled timestamps" which is a kind of multiversioning idea ex…

Look at the Raft protocol. In general you’d rather not integrate at the protocol layer; it’s standard to use a consistent store like etcd that implements Raft for the coordination/data that needs to be serializable. (Kubernetes uses etcd so it scales pretty well for a strongly-consistent k/v store.) You said “multiple datastores” so I’m assuming you have heterogenous data and something like CockroachDB isn’t an optio…

Thanks for your reply.

I've experimented with a toy Raft implementation but I haven't Jepsen tested that and it's incomplete

I did write a Jepsen test for a different eventually consistent protocol which understandably fails the linearizability test because I'm still learning - eventually consistent is not linearizable.

https://GitHub.com/samsquire/eventually-consistent-mesh

I want to have my cake and eat it too. Scalability and consistency.

Re: 50 years later, is two-phase locking the best we can do?

#59

Post by sfifs »

bawolff wrote: post #50
nine_k wrote: post #40

Earlier quoted context omitted.

If business software practices is not enough of a proof, look at any massive online games. They all use one central server as a source of truth about the game world, and broadcast that state to the clients. Anything a client reports that diverges from the central server view is either corrected, rejected, or becomes a reason to disconnect the client for cheating attempts. If you need strict order, that order should h…

Bitcoin: Am I joke to you? Everyone: yes.

Isn't bitcoin actually eventual consensus determined by increasing unlikelihood of finding a conflicting sequence of hashes?

Re: 50 years later, is two-phase locking the best we can do?

#60

Post by d0mine »

User23 wrote: post #18
onedognight wrote: post #5

2500 years later and the best hypotenuse algorithm is still Pythagoras’.

Funny you should say that. Here[1] is an interesting improvement. More interestingly he shows his work. [1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD09xx/EWD975...

Thank you for this gem.

It is a delight to read.

Post reply on HN