1.1.1

DescriptionOption
properties described in Using Java Management Extensions (JMX)
on page 295.
See Configuration Properties on page 319 for a complete list of boot
properties.
Description
A SQLFire locator allows peers (including other locators) in a distributed system to discover one another without
having to hard-code anything about other peers. The other mode of discovery is using multicast that requires the
peers to use the same multicast address and port for discovery.
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.
381
sqlf Launcher Commands