The higher frequency the transactions the more you get into quantum physics.
In reality, nobody cares if T-Mobile debited your account 0.01ms before WalMart.
[edit] what is important is isolation and consistency of the transactons.
The concern here isn't just order of transactions, but also synchronization. For instance, WalMart might charge you twice for a transaction if it appears to have happened at different times when it arrives in different data centers.
Also, the comment "The higher frequency the transactions the more you get into quantum physics." isn't relevant here. This is more in the realm of relativity than quantum physics. Even so, we aren't currently at a point where we need to worry about transactions happening at relativistic speeds.
WalMart cannot commit if someone else committed previously, they have to try again.
Atomicity is precisely what it is. There is no fuzziness there, you either do it or you don't.
The problem with current database designs is the idea of BeginTransaction, that function is the core of the problem.
"Transactions" in the real world are NOT completed until everyone agrees.
Consider you yourself enter into a transaction with your landlord, you BeginTransaction..
However during the negotiation you choose to disagree and back away from the deal.
That transaction, even though it took three months to decide was rejected (by either party).
The only "transaction" is the committed transaction.
Attempting to extend the landlord example... let's say that I'm your landlord and you have to pay me £1000 each month. You send the bank a message telling the to pay me the money. The bank may make several copies of that message and keep it around for their own reasons. Now, let's say that there are employees at that bank whose job it is to do go through all copies of all messages and make sure what they say is done. If they find a message from several months ago saying "transfer £1000 from you to me this month" and are somehow oblivious to which month it is, they may transfer an additional one thousand pounds even if it's already happened. It's not an exact analogy, but...
I'm seriously curious what is the disagreement. These guys already established atomic clocks are unnecessary. Very interested in which use cases require them.
Serializability is all about ensuring a single consistent ordering of events. Lots of algorithmic shortcuts you can take if all your nodes' clocks are precisely in sync.
If you investigate high frequency trading you will understand that the quantum phenomena that I'm talking about is not just me high on mushrooms but a real world thing.
The only "time" relevant is the time when the cluster agrees an atomic, isolated transaction is time to commit from its own perspective.
I went looking, and I don't see that in the current guidelines. I could be wrong about it being there before, but I was almost certain that it was at one point.
Seems like it used to say that you should only downvote comments that you think don't contribute anything of value to the conversation.
Just curious, because it seems to me that for quite a while now there have been a lot of comments that appear to get downvoted just because people don't agree with what the person said (and often there are no responses to counter, the person just gets downvoted).
Probably the most that I've written about downvotes on HN is at https://news.ycombinator.com/item?id=9440694.
https://news.ycombinator.com/item?id=117171
That said, I think many on HN do think that downvotes should be reserved for uncivil or unsubstantive comments as they don't contribute to the conversation. Some will still downvote for disagreement or for other reasons.
I think it's best not to let it bother you or worry about it because there's not much you can do about it, other than contribute as civilly, substantively, charitably, and in good faith.