Transaction – Timestamp Ordering. When is aborted transaction restarted

concurrencytimestamptransaction

(I don't know if this is the correct place to ask, since this is more like a theoretical question).

I have a question about restarting aborted transactions. I don't know when / at which point should restarting of the transaction(s) occur.

Example – using Basic Timestamp Ordering

w11(x), r12(x), r11(z), r13(x), w13(z), r12(z), w13(x), w14(x)

Initial values are:

read_ts(x) = write_ts(x) = read_ts(z) = write_ts(z) = 10

As we can see transaction 12 is aborted because it is trying to read value z, written already by T13 (older, T12 can't read it).

So in this case T12 is aborted and its timestamp is raised (to 15?). My question is when does the aborted transaction(s) restart?
(1) After all the non-aborted transactions are done, or (2) soon as possible (= restarts after next operation w13(x))?

In scenario 1, w14(x) would be done, and after that aborted transaction 12 would start (as T15).

In scenario 2 (soon as possible), transaction 12 (as T15) is restarted immediately after next operation w13(x). After that w14(x) is aborted (14 < 15) and restarted as T16

What is the correct order in this case? What does the restart actually mean? When do we restart an aborted transaction(s)?
I would like to see a practical example.

edit: changed the last operation to w14(x) instead of r14(x)

Best Answer

well, my teacher said that there is no clear answer since the methods varies. Some DBMSystems won't restart aborted transactions at all