From: Warren Young
Date: December 31 2007 1:01pm
Subject: Re: Lock Failed Exception
List-Archive: http://lists.mysql.com/plusplus/7326
Message-Id: <4778E837.5070500@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Simon Pickles wrote:
> 
> What is the cause of a "lock failed" mysqlpp exception, 

It means you're overlapping uses of either Connection or Query in a way 
that would cause run-time failures if the library didn't catch it first.

Be warned, we no longer bother catching such errors in v3.

> what is the best approach for dealing with it?  

Pretty much the same as the advice for using MySQL++ safely in a 
multithreaded program:

	http://tangentsoft.net/mysql++/test/doc/userman/threads.html

If your program already *is* multithreaded, so much the more important 
that you follow the user manual's advice.

>    template <class Type> void Select( std::vector<Type>& results, const 
> std::string& table, const std::string& where = "" )
>    {
>        m_sql = "SELECT * FROM ";

I'm guessing m_sql is a member variable of some class?  Why is it not 
just a local variable to this function?  This kind of loose data 
visibility is the sort of thing that leads to the problem you're reporting.

>            catch (const mysqlpp::Exception& er)
>            {
>                // Catch-all for any other MySQL++ exceptions
>                if ( strcmp( er.what(), "lock failed" ) == 0 )
>                {
>                    g_log->ERROR("Database Error: %s... retrying\n", 
> er.what() );
>                    continue;
>                }

It would be far better to just catch LockFailed here.

Testing exceptions based on the text of what() makes your code 
vulnerable to failures you can only catch at run time after upgrading 
MySQL++, if we change one of the error message strings.  Besides, the 
code to catch the correct exception would probably run faster than this 
strcmp stuff on the generic exception.