当事务在时间戳排序协议中回滚时，为什么会赋予它新的时间戳？
当事务在时间戳排序协议中回滚时，为什么会赋予它新的时间戳？ 为什么我们不保留旧的时间戳？
When a transaction is rolled back in timestamp ordering protocol, why is it given a new timestamp?
Why don`t we retain the old timestamp?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您正在谈论一个基于时间戳的操作的调度程序，并且允许回滚事务以其“旧”时间戳“重新进入调度队列”，那么最终效果可能是调度程序立即为来自该事务的任何请求提供最高优先级，其最终效果可能是导致该事务回滚的任何问题几乎立即重新出现，可能会导致新的回滚，从而导致新的“重新进入调度队列”等等。
或者“立即重新进入队列”的最终效果可能是所有其他事务都被停滞。
想象一下邮局里的一排人，有人提出了无法得到服务的请求，而该人被允许立即重新进入前面的队列（而不是后面）。那么需要多长时间才能轮到你呢？
If you are talking of a scheduler whose operation is timestamp-based, and a rolled-back transaction were allowed to "re-enter the scheduling queue" with its 'old' timestamp, then the net effect might be that the scheduler immediately gives the highest priority to any request coming from that transaction, and the net effect of THAT might be that whatever problem caused that transaction to roll back, re-appears almost instantaneously, perhaps causing a new rollback, which causes a new "re-entering the schedule queue", etc. etc.
Or the net effect of that "immediately re-entering the queue" could be that all other transactions are stalled.
Think of a queue of persons in the post office, and there is someone with a request which cannot be served, and that person were allowed to immediately re-enter the queue at the front (instead of at the back). How long would it then take before it gets to be your turn ?
因为可能有其他事务已使用新时间戳提交
如果 T1 将时间戳回滚到 X，则第三个事务将与 T2 的分配值产生冲突 增量和序列也是如此。如果您需要整体序列值（无间隙），则事务必须序列化，而这是以性能不佳为代价的。
Because there could be other transactions that had committed with the new timestamp
If T1 would rollback the timestamp to X then a third transaction would generate a conflict with T2's allocated value. Same goes for increment and sequences. If you need monolithic sequence values (no gaps) then the transactions have to serialize and this happens at the price of dismal performance.
在时间戳排序协议中，启动时分配给事务的时间戳用于识别与其他事务的潜在冲突。这些事务可能是更新此事务尝试读取的对象的事务，也可能是读取此事务尝试覆盖的值的事务。结果，当事务被中止并重新启动时（即为了保持可串行性），则该事务的所有操作将被重新执行，这就是需要分配新时间戳的原因。
从理论角度来看，在事务仍使用旧时间戳时再次重新运行操作将是不正确的。不安全，因为它会读取/覆盖新值，同时认为它位于较旧的时刻。从实际角度来看，如果事务继续使用旧时间戳，很可能它会继续中止并终止。不断重新启动，因为它会一次又一次地与相同的事务发生冲突。
In a timestamp ordering protocol, the timestamp assigned to the transaction when starting is used to identify potential conflicts with other transactions. These could be transactions that updated an object this transaction is trying to read or transactions that read the value this transaction is trying to overwrite. As a result, when a transaction is aborted and restarted (i.e. to maintain serializability), then all the operations of the transaction will be executed anew and this is the reason a new timestamp needs to be assigned.
From a theoretical perspective, rerunning the operations again while the transaction is still using the old timestamp would be incorrect & unsafe, since it would be reading/overwriting new values while thinking it's situated in an older moment in time. From a practical perspective, if the transaction keeps using the old timestamp, most likely it will keep aborting & restarting continuously, since it will keep conflicting with the same transactions again and again.