Peter Schuller <peter.schul...@infidyne.com> writes: >> The timestamp is an ever increasing clock so I wouldn't expect two api >> calls from the same machine in the same thread to have the same >> timestamp. It is perfectly allowed behavior for the read value to not >> agree with the write value. > > In the *particular* case of a single instantiation of a client I would > tend to expect it to actually guarantee strictly increasing time just > as a matter of thread-local consistency so that a single flow of > control can assume that writes will happen in the order in which they > are executed. (Is this actually the case for current high-level > clients?) > > But of course, there is no such guarantee in the distributed sense > either way.
The point is in reply to this message: Jérôme Verstrynge <jvers...@gmail.com> writes: > You are making my point (lol). No matter what an application writes, > it should re-read its owns write for determinism for a given timestamp > when other application instances are writing in the same 'table'. There is no such situation in Cassandra. An application may read things differently than it writes. You may not hold the timestamp constant and use that as a sort of locking mechanism. The timestamp is an every increasing clock. Cheers, Chris Dean
