About

Ranita works as an Assistant Professor at the Computer Science and Engineering Department at IIT Roorkee. She has completed her PhD from the Computer Science and Engineering Department at IIT Kharagpur. Before that, she has done her MTech from IIEST Shibpur, and got job offers from companies like Amazon, Samsung Labs etc. However, she preferred to pursue higher studies to stay in the field of academics and teaching. She believes in the motto of free education and contribution.

Role

Alma Mater:

PhD
IIT Kharagpur
2012 to 2016
Master of Engineering
Indian Institute of Engineering Science and Technology, Shibpur
2010 to 2012
Bachelor of Technology
Kalyani Government Engineering College
2005 to 2009

Experience:

Assistant Professor
Indian Institute of Technology Roorkee
2016
Project Linked Personnel
Indian Statistical Institute, Kolkata
2009 to 2010
Teacher
Answer
7 months 5 days ago

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
                   R(A)
R(A)
                             R(A)
         W(A)

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
                   R(A)
R(A)
         W(A)

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.

 
moreless
Teacher
Example text
8 months 3 weeks ago

This is an example of fan trap and chasm trap and how to resolve these scenarios. The following brief explanation may help you in understanding the concept which is usually found to be dubious across the web. This explanation is made in parity with the concept explained in Wikipedia (https://en.wikipedia.org/wiki/Entity–relationship_model#Model_usability_issues). You can also refer to https://db.grussell.org/section005.html to understand in detail.

moreless
Teacher
Example text
10 months 1 week ago

You are very close to the answer. But, there is one catch; the first row of pixels (at y = 0) and the last row of pixels (at y = 37) are not full length. You may try to modify the approach accordingly to get to the correct answer. Very good presentation, by the way.

moreless
Teacher
Example text
10 months 1 week ago

Consider the attribute set ABCDEG and the FD set
AB → C, AC → B, AD → E, B → D, BC → A, E → G
Is the following decomposition of R(ABCDEG)
(a) dependency-preserving?
(b) lossless-join?
1: AB, BC, ABDE, EG
2: ABC, ACDE, ADG
Give proper justification for your answer.

moreless
jayantachakr's picture
Jayanta Chakraborty
innovwelt's picture
Arul
arvind.rawat's picture
Arvind Rawat
pritam's picture
Pritam Prasun
maheshkvchinnu's picture
Mahesh KV Chinnu
1300
arvind.rawat's picture
Arvind Rawat
1334
jaipoornasingh's picture
Jaipoorna Singh
1350
vinayyadav's picture
vinay yadav
1377
vijaybhan's picture
vijay bhan
1430
shrutisharma's picture
Shruti Sharma
1504
rajeshkpandey008's picture
Rajesh Kumar Pandey
1522
sachinmittal's picture
Sachin
1564
litucool's picture
Litu Cool
1567
krishnamadhav's picture
Krishna Madhav
1625
shakirhussain's picture
shakir qureshi
1661
debdeepmajila's picture
Debdeep Majila
1833
darklordnandan's picture
Nandan jha
1962
parthshah's picture
Parth Shah
2086
vinitasangwan's picture
Vinita Sangwan
2169

Pages

13 Dec 2017 - 7:50pm

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
                   R(A)
R(A)
                             R(A)
         W(A)

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
                   R(A)
R(A)
         W(A)

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.

 
more less

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.

more less

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.

more less

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).

more less

@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.

more less

Yes, you are right. The final result won't be changed won't be changed.

more less

The extra conditions as you are putting in the query on billunit, payperiod, and earningdeduction should be done for both tables a and b.

more less

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.

more less

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;

more less

Pages