Client-Server Deployment

In an environment where hundreds or thousands of application clients need access to data, it is impractical for all clients to be members of a single distributed system, connected to each other, as with embedded peer-to-peer. To support many clients, you can deploy SQLFire as a cluster of standalone server processes (called SQLFire servers).

Understanding Client-Server Deployment

Each SQLFire server runs in its own process and provides network server functionality to manage connections to clients and other servers in the cluster. Although each SQLFire server runs in a standalone process, all servers become part of a single distributed system with direct connectivity to each other.

In the client-server deployment model, the client driver is lightweight (less than 1MB) and is implemented as a thin JDBC driver for Java applications, or as an ADO.NET for Microsoft .NET and Mono applications. In contrast to the SQLFire peer JDBC driver, the JDBC thin driver and ADO.NET driver only provide connectivity to an existing cluster of SQLFire servers or peer client members. Thin clients do not host or persist cluster data, and they do not directly participate in distributed queries that execute in the cluster.

Thin clients initially connect to only one server at a time. Multiple thin-client connections can be load-balanced across all SQLFire servers in the cluster.

After establishing a connection to a cluster, JDBC thin-clients have the ability to directly access multiple SQLFire members when executing queries. This provides single-hop access to data in the cluster for lightweight client applications.

Deciding When to Use the Client-Server Model

Unlike the embedded peer-to-peer model that supports only Java applications, the client-server deployment model allows Java, Microsoft .NET, and Mono applications to access SQLFire.

Here are typical scenarios in which you would use the client-server model rather than embedded peer-to-peer:

  • When you must support numerous clients, and scalability is a more important factor than distribution latency.
  • When the clients have a short life span. It may be desirable to keep the clients separated from the data stores (peers or servers). If peer clients continually attach to an embedded cluster, the overhead of re-creating data from disk or another repository becomes too expensive, and a client-server deployment should be considered instead.
  • When clients reside on desktop computers or connect over a remote network. Peer connectivity between clients may be impossible or undesirable because of firewalls and other network boundaries.