Dr. Sun,

Suppose T1 requests an exclusive lock on Block 1, but T2 and T3 already have a shared lock on Block 1. If T1 is older than T2, but younger than T3, then what happens to T1? Does T1 wait or does it die?

just to clarify, the wait-die algorithm only applies to when transactions are trying to obtain an xLock an a block, right? since shared locks can automatically be granted?

cysun wrote:

victormejia wrote:

... since shared locks can automatically be granted?

What if another transaction is holding an xlock?

Ohh I see. Well the current implementation of sLock() checks for that, but I realized it is still implementing the time-limit strategy. So for xLock() we check for no locks at all, and for sLocks we check for xLocks(), implementing wait-die for both, right?

Also, to rollback a transaction, is it enough to just throw the LockAbortException in the LockTable's xLock and sLock, or do have to catch it in the recovery manager, then throw it again so that the transaction get catch it and to a this.rollback()? I was a little confused about this.

victormejia wrote:

...

Also, to rollback a transaction, is it enough to just throw the LockAbortException in the LockTable's xLock and sLock, or do have to catch it in the recovery manager, then throw it again so that the transaction get catch it and to a this.rollback()? I was a little confused about this.

Throw an exception is enough.

cysun wrote:

victormejia wrote:

I have the following code:

 

 

public String getString(Block blk, int offset) {

  try{

  concurMgr.sLock(blk,this.txnum);

  Buffer buff = myBuffers.getBuffer(blk);

  return buff.getString(offset);

   

  }

  catch(LockAbortException e){

  this.rollback();

  }

 

}

 

I made it so that the sLock and xLock functions throw an exception if the requesting transaction is newer than the transactions that have a lock on the requested block. this would notify the transaction to rollback. However, I still have to return a string. If I have this situation and the transactions rollsback, what string do I return in order to safely call tx.getString(...) in my test code? And what int would I return for the getInt() function?

First of all, please don't post complete code.

Secondly, you don't need to catch the exception and rollback there. Under normal operations, there are various places in simpledb.remote (e.g. connection, resultset etc.) that catch exceptions and initiate rollback. For testing purpose, you can add catch and rollback to your test code.