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.
