1.1

In some cases you may want to embed a SQLFire accessor. This is a SQLFire member that does not host data,
but otherwise participates in the cluster. This code starts an accessor and also uses the locator for discovery:
Properties props = new Properties();
// add desired properties if required.
props.setProperty("server-groups", “sg3”);
props.setProperty("locators", “localhost[22343]”);
props.setProperty(“host-data”, “false”);
FabricServer server = FabricServiceManager.getFabricServerInstance();
server.start(props);
After starting a peer client, locator, or accessor as above, an application can obtain a connection:
String embedConnURL = "jdbc:sqlfire:";
Properties connProps = new Properties();
connProps.setProperty(“user”, “tom”);
connProps.setProperty(“password”, “tomspassword”);
Connection conn = DriverManager.getConnection(embedConnURL, connProps);
// create a table using this connection
Statement s = conn.createStatement();
st.execute(“create table customer
(id int not null, name varchar(100) not null”);
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 on page 212
• Deciding When to Use the Client-Server Model on page 212
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:
vFabric SQLFire User's Guide212
Deploying vFabric SQLFire