Thanks Warren, very good advice as always.
Linux user #458601 - http://counter.li.org.
Warren Young wrote:
> 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.
>
