1.1

Note: To avoid degrading the performance of the network server, use the smallest number of concurrent
single-hop threads that satisfy performance requirements.
Configuring TCP Keepalive Settings
By default, SQLFire servers use a TCP keepalive probe to help determine when clients have gone offline. SQLFire
thin clients can also use these keepalive settings to accurately determine when a server has gone offline. The
relevant configuration properties are:
• keepalive-count on page 329
• keepalive-idle on page 329
• keepalive-interval on page 330
To use these properties with a SQLFire thin client, include the jna.jar library in your CLASSPATH.
Note: Windows platforms do not support per-socket configuration for keepalive-count. As an
alternative, you can configure a system-wide keepalive-count value in some versions of Windows.
See http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220%28v=vs.85%29.aspx. Windows
Vista and later versions keep this value fixed at 10.
Note: On Solaris platforms prior to r10, system-wide TCP keepalive settings must be changed to larger
values (approximately 30 seconds) in order to detect server failures by clients and vice versa. See
http://docs.oracle.com/cd/E19082-01/819-2724/fsvdg/index.html. This also applies to other non-Linux,
non-Windows platforms. For example, see
http://www-01.ibm.com/support/docview.wss?uid=swg21231084.
Thin Client Driver Limitations
When the default batching mode is enabled for transactions, SQLFire detects any conflicts in DML operations
lazily. DML conflicts may be thrown by the system at some point later in the transaction (for example, even
when executing queries or at commit time). You can configure SQLFire to immediately detect conflicts at
operation time by setting the gemfire.tx-disable-batching system property to "true" on all data store
members in the distributed system.
Note: Enabling gemfire.tx-disable-batching can degrade performance significantly. Enable
this option only after you have thoroughly tested the setting in your system and have determined that the
performance tradeoff is necessary to provide immediate conflict detection with thin clients.
If you use the thin client driver to perform an insert to table that has no primary key, an automatic retry of the
insert due to a failover (available when connecting via a locator member) can result in duplicate rows being
added to the table.
The thin-client driver has the following limitations when the single-hop connection property is enabled:
• Single-hop access is not provided when using transactions or WAN replication.
Note: Do not enable single-hop access when using transactions or WAN configurations, as it can lead
to unexpected behavior.
• Single-hop access is only supported for partitioned tables where the partitioning column(s) are of the basic
data types: integer, long, double, decimal, char, varchar, and real. If a table is partitioned on a column having
any other data type (like date, time, timestamp, blob, clob, and so forth), then queries on that tables are not
considered for single-hop execution.
115
Developing Java Clients and Peers