Hi Doug,
Doug McNaught wrote:
>
>Creating and destroying database connections on the fly is kind of
>inefficient, but shouldn't cause the problems you're seeing.
>
But doing otherwise has the problem that if for some reason
the connection fails (or drops at some point), then it's gone
forever (in libpq++, there is a way to check if the connection
is alive, but I see no method to reconnect; only when creating
the PgDatabase or PgConnection object does it connect to
the database -- in fact, this was precisely the bug I was
referring to, the one that led to the referential integrity
violations right now).
>
>Right. Perhaps the client-side library isn't handling it properly.
>
>Might be time to dig in with a debugger. If you can trigger the
>referential integrity violation at will, do so and step through the
>libpq++ code with gdb (or whatever)--see if it handles the error from
>the server properly (you'll need to read up on the wire protocol).
>
Ouff!! This sounds sooo scary!! :-)
But I guess if that is the problem, then I might completely
eliminate it with a mutex for access to the database. I.e.,
any time I execute *any* SQL statement, then I lock the
mutex.
Hmmm, however, that doesn't fit too well the fact that
it is one specific insert statement that *always* causes
the error. Also, before the most recent changes, I had
very few of these errors (about 20 in a month and a half
of activity, versus a couple hundred in just two days),
and before, I was doing the login in the main thread,
and the logs to database in a separate thread... Hmm,
intriguing...
I guess I'm going to try using a mutex for any access
to the database as my first step, to *determine* if the
problem is related to concurrent database accesses
from the two threads. (hmmm, at this point, I wonder
if it is about time to upgrade to 7.3)
Thanks a lot -- and thanks to Tom -- for your comments
and suggestions!
Cheers,
Carlos
--