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 GemFire XD as a cluster of standalone server processes (called GemFire XD servers).
Understanding Client-Server Deployment
Each GemFire XD server runs in its own process and provides network server functionality to manage connections to clients and other servers in the cluster. Although each GemFire XD 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, an ADO.NET driver for .NET or Mono applications, or as an ODBC driver. In contrast to the GemFire XD peer JDBC driver, the JDBC thin client driver, ODBC driver, and ADO.NET driver only provide connectivity to an existing cluster of GemFire XD 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.
gfxd> connect client 'server_hostname:server_port/;load-balance=false'
After establishing a connection to a cluster, JDBC thin-clients have the ability to directly access multiple GemFire XD 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, ODBC, and ADO.NET applications to access GemFire XD.
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.