List:MySQL++« Previous MessageNext Message »
From:Raymond Boettcher Date:April 5 2011 6:43am
Subject:Re: thread_start() should ALWAYS be called after mysql_init()
View as plain text  
--- On Mon, 4/4/11, Warren Young <mysqlpp@stripped> wrote:
>> I meant #1, by the way: reflect the C API requirements into the MySQL++
> docs.  That is to say, it is the only option because there is no way at the base
> ConnectionPool level that MySQL++ could get this right?

That's good to know...  I had some problems with mysql++ in the past using
threads.  My solution was to declare mysql++ from a global level, then make sure I
"StoreQueryResult" (on a local level) instead of "Use" to prevent SQL++ from staying busy
by keeping a pointer in the records (as another query may destroy the other threads access
to that pointer).  From there I just maintain a Mutex Lock whenever a call to MySQL++
was being made.  I always called it something silly like &SQLLocker...  I
can construct the query and everything before establishing the lock since the
mysqlpp::query was a local declaration, it's just the ".exec" that needed a lock before
doing.  It may
 use a little more memory but it's insanely cheep these days and accessing a stored
record is quicker than accessing a record via a DB Pointer.  If your query result is
going to be so big that it may affect available memory, it might be time to adjust your
query to be a little more specific...  MySQL in itself supports a number of
functions and can easily add or subtract values from many different rows and return a
single row to your query with the answer.  This is much more effective than the
query all and add/subtract yourself scheme which IMO is just bad practice...

At one point I thought about making each connection local but keeping the connection
criteria as global variables, thereby establishing a connection to the DB for each
thread.  As long as I stick to my "StoreQueryResult" method of doing things, I
shouldn't have to worrie about running into database locks due to other threads... 
But even then SQL++ should simply "wait-for-unlock" until the other thread is done
modifying that table.  I always check to make sure the query was successful anyhow.

Raymond Boettcher

Thread
thread_start() should ALWAYS be called after mysql_init()KiberGus30 Mar
  • Re: thread_start() should ALWAYS be called after mysql_init()Jonathan Wakely30 Mar
    • Re: thread_start() should ALWAYS be called after mysql_init()KiberGus30 Mar
      • Re: thread_start() should ALWAYS be called after mysql_init()Warren Young31 Mar
Re: thread_start() should ALWAYS be called after mysql_init()KiberGus4 Apr
  • Re: thread_start() should ALWAYS be called after mysql_init()KiberGus4 Apr
  • Re: thread_start() should ALWAYS be called after mysql_init()Warren Young4 Apr
    • Re: thread_start() should ALWAYS be called after mysql_init()Warren Young4 Apr
Re: thread_start() should ALWAYS be called after mysql_init()Raymond Boettcher5 Apr