3 ms·
usual problem is when you try to model logical causality (a before b) with physical time (a.timestamp < b.timestamp) logical causality does not represent poor
by preseinger 3y ago
usual problem is when you try to model logical causality (a before b) with physical time (a.timestamp < b.timestamp)
logical causality does not represent poor engineering practice :)
- slt2021 3y agothis only applies if you carry over physical time from one machine to another, assuming perfect physical synchronization of time. if you stick to a single source of truth - only one machine's time is used as a source of truth - then the problem disappears. for example instead of using java/your-language's time() function (which could be out of sync across different app nodes) just use database's internal CURRENT_TIMESTAMP() when writing to db. another alternative is compare timestamps with up to 1 minute/hour precision, if you carry over time from one machine to another. That way you have a a buffer of time for different machines to synchronize clocks over NTP
- preseinger 3y agoif you can delegate synchronization/ordering to the monotonic clock of a single machine, then you should definitely do that :) but that's a sort of trivial base case -- the interesting bit is when you can't make that kind of simplifying assumption