1.1

System.out.println("VendorError: " + ex.getErrorCode());
}
Thin Client Failover
When you use the thin client to connect to a SQLFire locator member (rather than directly to a SQLFire server),
the thin client driver can provide automatic failover if the initial connection to the distributed system is lost. See
sqlf locator on page 369.
Enabling Single-Hop Data Access
By default, using the thin-client driver provides either one-hop or two-hop access to the data for executing queries
or DML statements. One-hop access is available if the client's SQL statements work against data that happens
to reside on the SQLFire member to which the thin client has connected. All other cases result in one-hop or
two-hop access to the data: the SQL statement is evaluated first on the SQLFire member to which the client is
connected, and if necessary, that server routes the query to other members in the cluster that host the actual data
for the statement.
SQLFire provides the option to provide single-hop access to data for certain queries when using a thin client
connection. To use this option, set the single-hop-enabled connection property to true when connecting with the
thin client driver. For example:
jdbc:sqlfire://myHostName:1527/;single-hop-enabled=true
Or, from within the sqlf utility:
connect client 'myHostName:1527;single-hop-enabled=true'
Note: Single-hop access for thin clients requires SQLFire data store members in the distributed system
to run a network server for direct client access. Configure each data store with network server functionality
even if you use a locator for member discovery. See Starting a Network Server on page 110.
Single-hop access is provided only for prepared statements. When you enable single-hop access on a connection
and then prepare a prepared statement, the local SQLFire server adds data distribution information to other
SQLFire server members in the response of the prepare message. When the prepared statement is executed, the
client uses the added parameter and information fetched from the connected server to determine the exact SQLFire
server on which it can find the data locally; it then directs the execution to that server.
The following types of queries are good candidates for single-hop access:
• Queries that have a WHERE clause on the partitioning columns of a table.
• Primary key-based SELECT statements where the primary key is also the partitioning key.
• IN-based WHERE clauses on partitioning columns.
If the client cannot determine the location of the data based on the WHERE clause, then it defaults to standard
two-hop execution. Single-hop execution is performed only when the client can be absolutely certain of the
location of data that is touched by the query.
Internally, the client JVM maintains a pool of connections that is shared by all of the prepared statements that
might execute statements with single-hop access. For each SQLFire server, the client maintains a queue of
connections that can grow to a maximum number of connection specified by the
sqlfire.single-hop-max-connections system property. After this maximum number of connections has been created
for a particular server, further single-hop executions must wait for a connection to become available in the queue.
If the number of connections created for a particular SQLFire server has not reached the maximum, then the
client creates a new connection on the fly, uses it, and then returns it back to the connection. The default value
for sqlfire.single-hop-max-connections is 5 connections per server. If you are developing a client that requires
more concurrent connections per server for single-hop access, increase the maximum number of connections
per server using the sqlfire.single-hop-max-connections system property.
vFabric SQLFire User's Guide114
Developing Applications with SQLFire