Author: mysqlpp
Date: Sun Apr 26 05:41:40 2009
New Revision: 2508
URL: http://svn.gna.org/viewcvs/mysqlpp?rev=2508&view=rev
Log:
In the user manual, noted that setting the "reconnect" option on new
connections created for a ConnectionPool can be a good idea, but also
why it's not done by default.
Modified:
trunk/doc/userman/threads.dbx
Modified: trunk/doc/userman/threads.dbx
URL:
http://svn.gna.org/viewcvs/mysqlpp/trunk/doc/userman/threads.dbx?rev=2508&r1=2507&r2=2508&view=diff
==============================================================================
--- trunk/doc/userman/threads.dbx (original)
+++ trunk/doc/userman/threads.dbx Sun Apr 26 05:41:40 2009
@@ -158,6 +158,19 @@
derivative, you might consider making it a Singleton (see Gamma
et al.), since there should only be one pool in a program.</para>
+ <para>Another thing you might consider doing is passing a
+ <ulink url="ReconnectOption" type="classref"/> object to
+ <methodname>Connection::set_option()</methodname> in your
+ <methodname>create()</methodname> override before returning the
+ new <classname>Connection</classname> pointer. This will cause
+ the underlying MySQL C API to try to reconnect to the database
+ server if a query fails because the connection was dropped
+ by the server. This can happen if the DB server is allowed to
+ restart out from under your application. In many applications,
+ this isn’t allowed, or if it does happen, you might want
+ your code to be able to detect it, so MySQL++ doesn’t set
+ this option for you automatically.</para>
+
<para>Here is an example showing how to use connection pools with
threads:</para>
_______________________________________________
Mysqlpp-commits mailing list
[email protected]
https://mail.gna.org/listinfo/mysqlpp-commits
