Give an example of a schedule of read/write requests that is accepted by a multiversion concurrency control in which transaction T1 starts after transaction T2 commits, yet T1 precedes T2 in the serial order. Such a schedule can have the following nonintuitive behavior (even though it is serializable): you deposit money in your bank account; your transaction commits; later you start a newtransaction that reads the amount in your account and finds that the amount you deposited is not there. (Hint: The schedule is allowed to contain additional transactions.)

What will be an ideal response?

r3(x) w2(x) commit2 r1(y) w3(y) commit3 r1(x) commit1 The order is T1 T3 T2. Therefore the last read of T1 on x does not see the write of x
made by T2. Thus T1 is before T2 even though it started after T2 committed. (Note
that the serialization order is the reverse of the commit order.)