29 messages in com.mysql.lists.plusplusRE: Sample files -- BadQuery w/Errnum...
FromSent OnAttachments
Warren Young11 Jul 2007 14:47 
Jim Wallace20 Sep 2007 08:47 
Warren Young21 Sep 2007 15:11 
Jim Wallace25 Sep 2007 06:00 
Jim Wallace25 Sep 2007 07:42 
Jim Wallace26 Sep 2007 06:28 
Warren Young26 Sep 2007 12:20 
Warren Young26 Sep 2007 13:24 
Warren Young26 Sep 2007 13:28 
Jim Wallace04 Oct 2007 19:40 
Warren Young05 Oct 2007 08:35 
Jim Wallace24 Oct 2007 08:12 
Jim Wallace24 Oct 2007 11:39 
Jim Wallace24 Oct 2007 11:40 
Jim Wallace24 Oct 2007 11:41 
Jim Wallace24 Oct 2007 11:42 
Jim Wallace24 Oct 2007 11:43 
Warren Young25 Oct 2007 05:43 
Warren Young25 Oct 2007 06:15 
Warren Young25 Oct 2007 07:05 
Warren Young25 Oct 2007 07:23 
Jim Wallace25 Oct 2007 07:52 
Jim Wallace25 Oct 2007 07:53 
Jim Wallace25 Oct 2007 08:48 
Warren Young25 Oct 2007 09:34 
Jim Wallace25 Oct 2007 09:51 
Jim Wallace25 Oct 2007 10:59 
Warren Young25 Oct 2007 11:25 
Jim Wallace25 Oct 2007 11:34 
Subject:RE: Sample files -- BadQuery w/Errnum patch part 4
From:Jim Wallace (jwal@kaneva.com)
Date:10/25/2007 08:48:02 AM
List:com.mysql.lists.plusplus

I put some inline comments in. I'll redo the samples after we hammer this out.

-----Original Message----- From: Warren Young [mailto:mysq@etr-usa.com] Sent: Thursday, October 25, 2007 10:24 AM To: MySQL++ Mailing List Subject: Re: Sample files -- BadQuery w/Errnum patch part 4

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.

Ok

2. Why does the first example need the loop? The second pass isn't actually needed to make it deadlock, is it?

Not to get the deadlock, but to have it succeed, it must do the second pass since the first pass throws the exception, rolls back the transaction. In the exception handling, the what_errnum() is checked, which will not be the same as errnum() as the output shows.

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?

I thought about doing it and actually had #ifdef's originally. The problem is that deadlock2 hangs waiting for the lock 1. Once deadlock1 tries to get lock 2 (which deadlock2 has), it immediately gets the deadlock exception, and rolls back, releasing lock1 so deadlock2 completes ok. And after deadlock2 completes, deadlock1 can retry and succeed.

I couldn't see how to do it since deadlock2 hangs, and deadlock one needs to wait for it to get in the hung state to trigger the deadlock. Threads would have worked, but I didn't want to get into x-platform issues.

If you have some suggestions, I'd be happy to try them.