--- 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
