When a transaction is rolled back in timestamp ordering protocol why is it given a new timestamp?

When a transa开发者_如何学Pythonction is rolled back in timestamp ordering protocol, why is it given a new timestamp? Why don`t we retain the old timestamp?

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 ?

Because there could be other transactions that had committed with the new timestamp

• Initial timestamp is at X
• Transaction T1 starts
• T1 allocates timestamp increments it to value to X+1
• Transaction T2 starts
• T2 allocates timestamp increments it to value to X+2
• T2 commits
• T1 rolls back

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.