1.0

A locator can be started on its own, or can be embedded in a server with the full SQLFire engine. Standalone
locators are also required for systems that enable network partitioning management. To start embedded locators
use the "-start-locator" option to the SQLFire server.
Note: Locators are the recommended discovery method for production systems. Additionally, running
standalone locators provides the highest reliability and availability for the locator service as a whole.
Because a locator has no data or meta-data available, it cannot directly service any of the user table related SQL
statements from thin clients. It can only service queries involving inbuilt system tables, and inbuilt system
procedure calls. Clients use the connection as a control connection to query the locator for the server with the
least amount of load (measured in terms of other active client connections) and transparently create the actual
data connection to the server as returned by the locator. The client also keeps track of all the other locators and
peers in the distributed system by querying the locator. This practice avoids creating multiple control connections
for the same distributed system. If the client detects any two separate user connections referring to locators or
servers in the same distributed system then it will use the same control connection for both. The list of all locators
and peers is also used for failover if the control connection itself fails.
SQLFire locators are necessary for load-balanced client connections, and for full availability of the transparent
failover functionality provided by the thin client driver (high-availability, or HA in short). Without locators
client connections cannot be load-balanced. Even though clients try to fail over transparently to other servers
without locators, this behavior is not as reliable as using locators, and failover may not work transparently if
multiple servers fail in quick succession.
Always start a locator as a background process. This is required as the locator may not have been the last peer
to go down in the cluster and thus will require the other cluster locators to also come up before it can be certain
that its data is consistent with others. Note that each locator locally persists a copy of the data dictionary required
for basic functioning and may have to wait for other locators to come back online to ensure that it has all the
latest updates to the data dictionary.
Example
Starting a locator generates output such as the following. XXX is the path of current working directory.
Starting SQLFire Locator using peer discovery on: 0.0.0.0[10334]
Starting network server for SQLFire Locator at address
localhost/127.0.0.1[1527]
SQLFire Locator pid: 3722 status:running
Logs generated in <XXX>/sqlflocator.log
By default sqlf locator start starts the server process locally and uses the current working directory to
store logs, locator state and the data dictionary, and uses default TCP port 10334 for peer discovery. A standalone
locator does not store any user table data or table meta-data.
A sub-directory called datadictionary is created by default in the current working directory of the locator
and contains the persistent meta-data of the DDLs required for startup by locator (for example, authentication
related privileges) that have been executed in the distributed system from any of the clients or peers. This directory
is necessary for a SQLFire locator to startup and function properly.
As the output above indicates, a network server is also started by default that binds to localhost on port 1527.
This service allows thin clients to connect to one of the servers and execute SQL commands using the DRDA
protocol.
sqlf Logging Support
You can specify JDBC boot properties with sqlf server and sqlf locator commands to configure the
log file location and log severity level for SQLFire servers and locators, respectively.
Configuring and Using SQLFire Log Files on page 249 provides more information.
vFabric SQLFire User's Guide352
vFabric SQLFire Reference