Olav,
Thanks for the review.
> Olav Sandstaa wrote:
> * I think we try to avoid adding "engine falcon" to create statements
> since we have already set default engine in our tests?
Done, Will push this benign change next chance I get.
> * Test case 1: will this test fail if the second update (which is
> supposed to block) do not block? Would it be possible to show that it
> actually blocks?
If it does not block, the output will be before the COMMIT instead of
after it. The evidence that there is a lock on that record is that it
waits. Whether the transaction commits or rolls back, the UPDATE will
then succeed after the wait.
> * Test case 1: would it be good to add a "Check results for test 1"
> section that did a select * from the tables?
Done, Will push this change next chance I get.
> * Test case 2: Here you do a "Connect to default and ROLLBACK TO SP1"
> (but issue a ROLLBACK command?) but this seems like both the initially
> "waiting" updates have gone through? both 1111 and 2222 have been
> updated. Is this correct?
Yes, they happen as soon as the rollback happens. There is a sleep to
make sure that they get committed before the following select.
I will change ROLLBACK TO SP1 to ROLLBACK.
> * Test case 3: will this test fail in anyway if the first update does
> not block? Would it be possible to show that it actually blocks?
If it does not block, the output will be before the COMMIT instead of
after it.
