If the two transactions don't have any overlapping splits then their relative timestamps can be anything, as long as there is no causality created between them outside the system. Only if there is causality between them do their timestamps have to be in a certain order.
Causality outside the system can only be created if the commit time of one transaction is strictly before the arrive time of the other transaction.
As stated in my earlier post, there are no ordering guarantees for transactions that are sent one after the other to the database, if the first one wasn't commit-acked before the second one was sent. To my knowledge, no database in the world (single-node or distributed) offers such a guarantee, at least for transactions sent by different client processes. This is where a lot of people trip up.
So if you have a for-loop from 1 to 10 that async sends 10 transactions (and you're not waiting for ack before sending the next one), those 10 transactions can be ordered/timestamped/applied in any order by the database and this would be correct behavior by even the strictest database models.
In Spanner if two transactions have overlapping splits then there will be locking and they will be correctly serialized since Spanner is not multi-leader. The same row cannot be written to by different Spanner machines at the same real-world time.
Your observation is actually correct - the timestamp order in Spanner will not perfectly reflect the order in which the transactions were written to the underlying data structure. But my point is that it doesn't need to because the way Spanner does it is still maximally correct.
Causality outside the system can only be created if the commit time of one transaction is strictly before the arrive time of the other transaction.
As stated in my earlier post, there are no ordering guarantees for transactions that are sent one after the other to the database, if the first one wasn't commit-acked before the second one was sent. To my knowledge, no database in the world (single-node or distributed) offers such a guarantee, at least for transactions sent by different client processes. This is where a lot of people trip up.
So if you have a for-loop from 1 to 10 that async sends 10 transactions (and you're not waiting for ack before sending the next one), those 10 transactions can be ordered/timestamped/applied in any order by the database and this would be correct behavior by even the strictest database models.
In Spanner if two transactions have overlapping splits then there will be locking and they will be correctly serialized since Spanner is not multi-leader. The same row cannot be written to by different Spanner machines at the same real-world time.
Your observation is actually correct - the timestamp order in Spanner will not perfectly reflect the order in which the transactions were written to the underlying data structure. But my point is that it doesn't need to because the way Spanner does it is still maximally correct.