Load Balancing With Connector/J - Oracle 5.0 Reference Manual

use this feature to validate connections. Depending on your connection pool and configuration, this
validation can be carried out at different times:
1. Before the pool returns a connection to the application.
2. When the application returns a connection to the pool.
3. During periodic checks of idle connections.
To use this feature, specify a validation query in your connection pool that starts with
*/. Note that the syntax must be exactly as specified. This will cause the driver send a ping to the
server and return a dummy lightweight result set. When using a
LoadBalancedConnection, the ping will be sent across all active connections.
It is critical that the syntax be specified correctly. The syntax needs to be exact for reasons of
efficiency, as this test is done for every statement that is executed:
protected static final String PING_MARKER = "/* ping */";
...
if (sql.charAt(0) == '/') {
if (sql.startsWith(PING_MARKER)) {
doPingInstead();
...
None of the following snippets will work, because the ping syntax is sensitive to whitespace,
capitalization, and placement:
sql = "/* PING */ SELECT 1";
sql = "SELECT 1 /* ping*/";
sql = "/*ping*/ SELECT 1";
sql = " /* ping */ SELECT 1";
sql = "/*to ping or not to ping*/ SELECT 1";
All of the previous statements will issue a normal
the lightweight ping. Further, for load-balanced connections, the statement will be executed against
one connection in the internal pool, rather than validating each underlying physical connection. This
results in the non-active physical connections assuming a stale state, and they may die. If Connector/
J then re-balances, it might select a dead connection, resulting in an exception being passed to the
application. To help prevent this, you can use
to validate the connection before use.
If your Connector/J deployment uses a connection pool that allows you to specify a validation query,
take advantage of it, but ensure that the query starts exactly with
important if you are using the load-balancing or replication-aware features of Connector/J, as it will help
keep alive connections which otherwise will go stale and die, causing problems later.

20.3.8. Load Balancing with Connector/J

Connector/J has long provided an effective means to distribute read/write load across multiple MySQL
server instances for Cluster or master-master replication deployments. Starting with Connector/J 5.1.3,
you can now dynamically configure load-balanced connections, with no service outage. In-process
transactions are not lost, and no application exceptions are generated if any application is trying to use
that particular server instance.
There are two connection string options associated with this functionality:
•
loadBalanceConnectionGroup
sources. This allows you to manage these JDBC sources within a single class loader in any
combination you choose. If they use the same configuration, and you want to manage them as a
logical single group, give them the same name. This is the key property for management: if you
do not define a name (string) for loadBalanceConnectionGroup, you cannot manage the
Load Balancing with Connector/J
SELECT
loadBalanceValidateConnectionOnSwapServer
– This provides the ability to group connections from different
2099
ReplicationConnection
statement and will not be transformed into
*/. This is particularly
/* ping
/* ping
or