View Forum Topic

Forums
CS422
About HW5

Author	Message
cysun Posts: 2935	Posted 17:09 Sep 01, 2009 \| I just finished grading the first part of HW5, and here are a few things I want to mention: For 14.25(c), remember that if a transaction is waiting on a lock, it cannot proceed, so for example if you show a schedule like "xl1(b1)...sl2(b1)...xl2(b2)...xl1(b2)" then say T2 is waiting for the lock on b1 and T1 is waiting on the lock on b2, it is wrong, because T2 would wait at sl2(b1) so it cannot proceed to do xl2(b2). For 14.25(d), nobody got the right answer except one which was kind of close. The key is to realize that the first operation in T2 is r2(b2) while the last operation in T1 is w1(b2). This means that r2(b2) must precede w1(b2) (otherwise the schedule is serial), which in turn means that all operations of T2 must precede w1(b2) because of 2PL. I'll let you fill in the rest of the steps. For 14.33(a), remember that there could be more than two transactions involved in a deadlock, so if you want to do a peudo proof, use T1,...,Tk instead of just T1 and T2.
cysun Posts: 2935	Posted 15:26 Sep 02, 2009 \| Regarding Ex 14.52. 1. Terminating a Java thread You should not use thread.stop() to terminate a thread because it's unsafe and will lead to unpredictable program behaviors. See the Thread API documentation for details. The proper way to terminate a thread is to call thread.interrupt(). It's rather tricky because the effect of an interrupt() call depends on whether the thread is in running/runnable state or not runnable state. Again see the API documentation for details. 2. Wait-die and Wound-wait These two protocols are quite similar in concept, but Wound-wait is a lot harder to implement in Java because it requires one thread to terminate another thread. Wait-die, however, does not require thread termination. The way wait-die works is this: in lockTable.lock(), if a transaction cannot acquire a lock and decides to abort, it raises a LockAbortException. This exception is caught in the run() method of the thread that runs the transaction, and transaction.rollback() is called in the catch block. This process is important for two things: a. Because an exception is raises, all operations after the operation that causes the exception will be skipped, which is the way it should be. b. The transaction may be aborted, but the thread still finishes normally (because the exception is handled in the catch block), so we avoid having to interrupt a thread.

Author

Message

cysun

Posts: 2935

Posted 17:09 Sep 01, 2009 |

I just finished grading the first part of HW5, and here are a few things I want to mention:

For 14.25(c), remember that if a transaction is waiting on a lock, it cannot proceed, so for example if you show a schedule like "xl1(b1)...sl2(b1)...xl2(b2)...xl1(b2)" then say T2 is waiting for the lock on b1 and T1 is waiting on the lock on b2, it is wrong, because T2 would wait at sl2(b1) so it cannot proceed to do xl2(b2).

For 14.25(d), nobody got the right answer except one which was kind of close. The key is to realize that the first operation in T2 is r2(b2) while the last operation in T1 is w1(b2). This means that r2(b2) must precede w1(b2) (otherwise the schedule is serial), which in turn means that all operations of T2 must precede w1(b2) because of 2PL. I'll let you fill in the rest of the steps.

For 14.33(a), remember that there could be more than two transactions involved in a deadlock, so if you want to do a peudo proof, use T1,...,Tk instead of just T1 and T2.

cysun

Posts: 2935

Posted 15:26 Sep 02, 2009 |

Regarding Ex 14.52.

1. Terminating a Java thread

You should not use thread.stop() to terminate a thread because it's unsafe and will lead to unpredictable program behaviors. See the Thread API documentation for details.

The proper way to terminate a thread is to call thread.interrupt(). It's rather tricky because the effect of an interrupt() call depends on whether the thread is in running/runnable state or not runnable state. Again see the API documentation for details.

2. Wait-die and Wound-wait

These two protocols are quite similar in concept, but Wound-wait is a lot harder to implement in Java because it requires one thread to terminate another thread. Wait-die, however, does not require thread termination. The way wait-die works is this: in lockTable.lock(), if a transaction cannot acquire a lock and decides to abort, it raises a LockAbortException. This exception is caught in the run() method of the thread that runs the transaction, and transaction.rollback() is called in the catch block. This process is important for two things:

a. Because an exception is raises, all operations after the operation that causes the exception will be skipped, which is the way it should be.

b. The transaction may be aborted, but the thread still finishes normally (because the exception is handled in the catch block), so we avoid having to interrupt a thread.