ADO _ConnectionPtr still throwing even after reopening connection [modified]
-
I've just encountered a bit of an issue while trying to do some sort of automatic recovery from a MySQL server crash to a C++ app. Basicly, once I catch a DB_E_ABORTLIMITREACHED somewhere in the app I set an event to perform a ->Close() and ->Open() (in a separate thread) and check if that worked OK. I keep doing this for each throw with the above error. Problem comes up when the Open() is theoretically ok again, all other apps that rely on that server are properly working with it again but any attempt at calling ->Execute() keeps throwing the same thing. Has anyone encountered this behaviour before and could shed some light on why and maybe how to fix? PS: After about 5 minutes of throwing that exception (after I restart MySQL that is) stuff miraculously starts working again, no more exceptions. PS2: Also tried clearing Errors, there aren't any there it seems. Here's a bit of code that might make things more clear:
_ConnectionPtr pConn;
// Some method in the app:
try
{
pConn->Execute(...); // doing this while MySQL went kaboom leads to a _com_error being thrown
}
catch (_com_error &e)
{
switch (e.Error())
{
case DB_E_ABORTLIMITREACHED:
SetEvent(hReconnectDBEvent);
break;
}
...
}// Connection thread:
while (keepChecking)
{
waitRes = WaitForMultipleObjects(..., 30000); // App exit, DB reconnect, half the db connection timeout
switch (waitRes)
{
case WAIT_OBJECT_the_reconnect_event:
if (pConn->State == adStateOpen)
{
pConn->Close();
}
pConn->Open(...); // returns 0 when MySQL is back upbreak; }}
Once connection is reopened ok attempts to Execute something still throw that exception for about 5 more minutes. After that everything returns back to normal.
Last modified: 1hr 5mins after originally posted -- clarification, code
-
I've just encountered a bit of an issue while trying to do some sort of automatic recovery from a MySQL server crash to a C++ app. Basicly, once I catch a DB_E_ABORTLIMITREACHED somewhere in the app I set an event to perform a ->Close() and ->Open() (in a separate thread) and check if that worked OK. I keep doing this for each throw with the above error. Problem comes up when the Open() is theoretically ok again, all other apps that rely on that server are properly working with it again but any attempt at calling ->Execute() keeps throwing the same thing. Has anyone encountered this behaviour before and could shed some light on why and maybe how to fix? PS: After about 5 minutes of throwing that exception (after I restart MySQL that is) stuff miraculously starts working again, no more exceptions. PS2: Also tried clearing Errors, there aren't any there it seems. Here's a bit of code that might make things more clear:
_ConnectionPtr pConn;
// Some method in the app:
try
{
pConn->Execute(...); // doing this while MySQL went kaboom leads to a _com_error being thrown
}
catch (_com_error &e)
{
switch (e.Error())
{
case DB_E_ABORTLIMITREACHED:
SetEvent(hReconnectDBEvent);
break;
}
...
}// Connection thread:
while (keepChecking)
{
waitRes = WaitForMultipleObjects(..., 30000); // App exit, DB reconnect, half the db connection timeout
switch (waitRes)
{
case WAIT_OBJECT_the_reconnect_event:
if (pConn->State == adStateOpen)
{
pConn->Close();
}
pConn->Open(...); // returns 0 when MySQL is back upbreak; }}
Once connection is reopened ok attempts to Execute something still throw that exception for about 5 more minutes. After that everything returns back to normal.
Last modified: 1hr 5mins after originally posted -- clarification, code
Is there any reason you suspect that this might be COM related and not MySQL related? As per the great MSDN, DB_E_ABORTLIMITREACHED means this - "Execution aborted because a resource limit has been reached; no results have been returned.". I am just guessing, but maybe you're hitting maximum concurrent connection limits (the fact that a restart of MySQL fixes the issue also supports this theory)? Are you using smart pointers for your ADO connection objects?
-- gleat http://blogorama.nerdworks.in[^] --
Number Two's eyes narrowed and became what are known in the Shouting and Killing People trade as cold slits, the idea presumably being to give your opponent the impression that you have lost your glasses or are having difficulty keeping awake. Why this is frightening is an, as yet, unresolved problem. -- HHGTG
-
Is there any reason you suspect that this might be COM related and not MySQL related? As per the great MSDN, DB_E_ABORTLIMITREACHED means this - "Execution aborted because a resource limit has been reached; no results have been returned.". I am just guessing, but maybe you're hitting maximum concurrent connection limits (the fact that a restart of MySQL fixes the issue also supports this theory)? Are you using smart pointers for your ADO connection objects?
-- gleat http://blogorama.nerdworks.in[^] --
Number Two's eyes narrowed and became what are known in the Shouting and Killing People trade as cold slits, the idea presumably being to give your opponent the impression that you have lost your glasses or are having difficulty keeping awake. Why this is frightening is an, as yet, unresolved problem. -- HHGTG
That isn't thrown randomly and MySQL restart doesn't fix it. If I stop MySQL (or for some weird reason the application is cut off from the SQL server) then this is thrown, with a message of "Connection to MySQL died" or something like that. After that I start MySQL back up my thought was that a reopening should allow me to work again but even if Open() works just fine (I manually force the exception after SQL is back up which leads to Open()), attempting Execute() throws the same exception as before, for about 5 minutes after which it magically works. And there is the possibility that MySQL might be the one doing this due to some weird timeout. And I only have 1 connection to MySQL which is supposed to be open all the time (communication is supposed to work even over a 9600bps line, opening connections every query can add quite a bit of ovehead when the same line is also used for App -> App Server comm).
-
That isn't thrown randomly and MySQL restart doesn't fix it. If I stop MySQL (or for some weird reason the application is cut off from the SQL server) then this is thrown, with a message of "Connection to MySQL died" or something like that. After that I start MySQL back up my thought was that a reopening should allow me to work again but even if Open() works just fine (I manually force the exception after SQL is back up which leads to Open()), attempting Execute() throws the same exception as before, for about 5 minutes after which it magically works. And there is the possibility that MySQL might be the one doing this due to some weird timeout. And I only have 1 connection to MySQL which is supposed to be open all the time (communication is supposed to work even over a 9600bps line, opening connections every query can add quite a bit of ovehead when the same line is also used for App -> App Server comm).
Sounds like the OLE DB driver is doing some kind of connection optimization by physically attempting an "open" only when a query is executed - a "lazy connect" if you will. One area you might want to look into is connection pooling. See if turning off connection pooling produces different results. MSDN has more[^] on this.
-- gleat http://blogorama.nerdworks.in[^] --
Number Two's eyes narrowed and became what are known in the Shouting and Killing People trade as cold slits, the idea presumably being to give your opponent the impression that you have lost your glasses or are having difficulty keeping awake. Why this is frightening is an, as yet, unresolved problem. -- HHGTG