Thanks Warren for your inputs.
Let me explain a bit further.
I am working with a daemon process which has to stay up even if the DB
goes away. I could make the process to abort when the connection goes
away and that will be the simplest way to deal with this. But this could
lead to other overheads of maintaining internal data integrity. So I
would prefer to keep the process alive and expect the DB to come back;
so that it can
reconnect -> re-initialise-connection -> do-processing.
Now in 3.0.9, as far as I could understand, when the reconnection
happens, the only way to identify this is to get the thread_id() and
compare it before and after any operation. ( Assuming that the
reconnection happens under the hood, when ever we try to operate on the
connection; is that right?! ). In that scenario, would it be possible to
have a call-back function which then can initialize the connection
before executing SQLs.
Warren Young wrote:
> Dino Korah wrote:
>>
>> I am working with 3.0.9 and there seems to be no way I can effectively
>> use it to reconnect in scenario where I need to run a set of SQLs to
>> setup the connection for real use in my application. They are mostly
>> session variables meant for auto_increment.
>
> It is not clear to me what your problem actually is. Why does it matter
> what SQL you're using? How does that affect connection management? Why
> do you need to reconnect in the first place?
>
> ReconnectOption exists to make the underlying C API library try to
> reconnect to the DB server if our connection to it gets dropped without
> the client's asking for it. That's why it's just a boolean option: yes
> enable this feature, or no don't do this.
