reset password
Author Message
jigar_gaglani
Posts: 16
Posted 15:10 Aug 27, 2009 |

Hello, 

       I have a doubt when we excecute 3 transactions concurrently. For eg: 

If,

---> Transaction A aquires Slock on block 1, then

----> Transaction B aquires Slock on block 2, then

-----> Transaction C tries to aquire Xlock on block 1 , as per simpledb code here it first goes for Slock & then upgrade it for Xlock, because of which it allows Transaction C to write on block 1 even though Transaction A is not yet committed. 

      Is it correct or there should be conflict and transaction C should rollback ?. 

Thanks.

cysun
Posts: 2935
Posted 15:18 Aug 27, 2009 |

A transaction cannot do lock upgrade if there are other transactions holding shared locks on the data.

jigar_gaglani
Posts: 16
Posted 15:21 Aug 27, 2009 |

Ok, thank you professor. It clearified.

cysun
Posts: 2935
Posted 15:41 Aug 27, 2009 |

Please see a better explaination of SimpleDB's locking implementation at http://sun.calstatela.edu/csns/forum/viewTopic.html?topicId=2118223. Basically the scenario you gave cannot happen because the code does check whether there are other shared locks before doing the lock upgrade.

Last edited by cysun at 15:41 Aug 27, 2009.