Possibly this is the same note.
The correct answer is (b) remains same. To understand this, let us revise the informal algorithm for Timestamp based protocol for concurrency control (copied from Wikipedia, you can also refer to the formal version of the algorithm there):
1) If a transaction wants to read an object,
a) but the transaction started before the object's write timestamp it means that something changed the object's data after the transaction started. In this case, the transaction is canceled and must be restarted.
b) and the transaction started after the object's write timestamp, it means that it is safe to read the object. In this case, if the transaction timestamp is after the object's read timestamp, the read timestamp is set to the transaction timestamp.
2) If a transaction wants to write to an object,
a) but the transaction started before the object's read timestamp it means that something has had a look at the object, and we assume it took a copy of the object's data. So we can't write to the object as that would make any copied data invalid, so the transaction is aborted and must be restarted.
b) and the transaction started before the object's write timestamp it means that something has changed the object since we started our transaction. In this case, we use the Thomas write rule and simply skip our write operation and continue as normal; the transaction does not have to be aborted or restarted
c) otherwise, the transaction writes to the object, and the object's write timestamp is set to the transaction's timestamp.
Now consider the following example schedule:
T1 T2 T3 T4
Consider that after the execution of the last R(A), T4 needs to rollback (as given in the question). So, RTS(A) was 4 and now we need to decide what should be the new RTS for A. Note that, the schedule at hand now is something like the following:
T1 T2 T3
Independent of T4, this schedule will have RTS(A) = 3 when T2 tries to write and hence T2 should be aborted by rule 2(a).
Now, after rollback of T4, consider option (a) i.e. changing the RTS(A) to 0. This will certainly allow W(A) by T2 to execute without any problem as it falls under rule 2(c) and hence violates concurrency by allowing T2 to write a data already read by T3.
Consider option (c) i.e. RTS(A) becomes equal to the timestamp of the transaction which read 'A' just before T4, in this example then RTS(A) becomes 1. And hence the same problem arises as choosing option (a).
Therefore, if we choose option (b) and keep the RTS(A) same as before i.e. 4, then W(A) by T2 will fall under rule 2(a) and hence will be aborted. So, option (b) is the correct answer.
This is why RTS is kept as the largest of the timestamps of the transactions which has read the data, and not the recent timestamp.
Unfortunately, he is not. The point both of you are missing is that we are trying to find the position of the newly inserted element (not just any random search element). The position of the newly inserted element is always on the path from new leaf to root. Please go through the question again to understand what it is asking for.
Then kindly create a separate thread for your discussion. As you are addressing 'your issue' on the comment thread of a posted question, it will confuse the students.
I am not exactly sure if it is a sarcasm here. Students are in learning phase, so they can always ask some doubt which is not that relevant. Doubts are called 'doubts' because the asker is not sure about the concept. A teacher's duty is to clarify it in a proper way, sarcasm does not solve problems.
In case of this very problem, it is a little misleading because it does not specify the internal structure of the heap. If the elements of the heap are stored in an array, we can always do a binary search among the elements in a particular path from leaf node to root. Even though heap itself does not support binary searching, but elements of a single path of a heap are always sorted and we can easily get parent and children of nodes from array indices, and so we can do binary search on those elements. The answer given by Leen Sharma (the asker herself) is correct which calculates the complexity as O(log log n).
PS: The comment on which I replied is below (as it was deleted by the user later and now my reply sounds kind of crazy).
@uddalakbhaduri That's a genuine doubt. However, if you revise the concept of insertion in a max-heap (you can refer to this link: https://en.wikipedia.org/wiki/Binary_heap#Insert or any standard book), you will see that the 'newly inserted element' always can be found on the path from 'new leaf' to root. It happens because how we insert the new element using up-heap operations only. That's why the solution of O(log log n) works.
@djg1981 That was a typo, just corrected. Thanks.
Yes, you are right. The final result won't be changed won't be changed.
The extra conditions as you are putting in the query on billunit, payperiod, and earningdeduction should be done for both tables a and b.
Yes, I forgot to mention that. Duplicate column names as he has shown in second table is not allowed. However, if the query written by me is ran, it will produce unique column names because a or b will be prefixed with the names. If new names for columns need to be given, we need to use 'as' to assign those.
Being consistent with the naming you have used in the first table and assuming that your table name is emploan, the query should be:
select a.empno, a.loan_ref_id, a.amount, b.loan_ref_id, b.amount from emploan a, emploan b where a.empno=b.empno and a.loan_ref_id <> b.loan_ref_id;