Patch for Bug 608032 - MySQL timeout and no attempt reconnect

Tom Van Braeckel tomvanbraeckel at gmail.com
Thu Feb 4 11:21:34 EST 2010


>
> On Thursday 4 February 2010, Tom Van Braeckel wrote:
> > Hi guys,
> >
> > Here's another patch - my first *code* patch to GnuCash !
> >
> > Rationale: When we try to open a database transaction, and the database
> > reports that the "server has gone away", we try to reconnect before
> failing
> > hard.
> >
> Hi,
>
> Thanks you for your patch. It looks like a good start, but to my limited
> knowledge of the sql backend, it seems incomplete.
>
> Here are my thoughts on the patch:
> * you test for an error by comparing with a string. I think it would
> probably
> be safer and definitely be more efficient to simply test for the error
> number
> returned by dbi_conn_error. It's possible that the error strings returned
> by
> MySQL are translated into other languages on other systems, so your string
> wouldn't always match.
>

Thanks for the feedback !
You're right - I've corrected this in the attached patch and cleaned it up a
bit - hope you like it :-)

Note that such string-based error checking is also done in other places
(such as the "mysql_error_fn" function in gnc-backend-dbi.c), perhaps I'll
rectify that in a future patch.


>
> * what happens if not only the connection had timed out, but something else
> changed as well (an administrator changed the login password for example) ?
> I
> mean you don't check the results of dbi_connect or the second
> dbi_conn_queryf.
>

Good question. When that happens, GnuCash will behave as it did before
("Could not save..." error). There's room for improvement there (such as
asking for the new login password) but I feel like that's a different issue.


>
> * I also think there may be more useful places to check for a connection
> timeout, not only at the beginning of transactions. I found several
> occurences
> of dbi_conn_query and dbi_conn_queryf some of which could be called passed
> a
> timeout.
>

Well, normally these timeouts have high values (8 hours in a default MySQL
installation). Since a database query normally begins with a "begin
transaction" (as it should) and a transaction is typically very short lived,
I don't think the connection will ever time out between "begin transaction"
and an actual statement. Unless I'm missing something...



>
> As said in the beginning, I'm not the dbi expert, so maybe my comments are
> off
> mark or plain silly.
>
> > I've also attached it to the bug report, and taken the liberty to add
> >  myself to the AUTHORS file.
> > I hope that's customary here, and I apologise if it's not...
> >
> I think this is quite ok. I would just like to ask you to put your name in
> alpabetical order which I think would put you between Richard -Gilligan-
> Uschold and Matthew Vanecek.
>

Done :-)


>
>
> > Thanks again for this great software,
> >
> Keep submitting patches !


> > Tom Van Braeckel
> > GSM: 0032 (0) 486 63 58 04
> >
>
> Geert
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MySQL_timeout_reconnect.patch
Type: text/x-diff
Size: 1360 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20100204/de193ced/attachment.bin>


More information about the gnucash-devel mailing list