Jim Wallace wrote:
> + deadlock1 and deadlock2: Tests detecting a deadlock between
> + two transactions, using the BadQuery::what_errnum() value
I've looked at these, and have some concerns:
1. The database creation stuff belongs in resetdb.
2. Why does the first example need the loop? The second pass isn't
actually needed to make it deadlock, is it?
3. If the new tables are created and populated ahead of time by resetdb,
it seems to me that the two programs are so close to each other that it
should be possible to have just one program, which you run twice. I
don't quite understand the nature of the deadlock, but maybe if you just
add second cin.getline() call between the two SELECT queries, so the
first is sitting and waiting halfway through when you start the second?