1.1.1

Embedded Peer-to-Peer Deployment
The embedded, peer-to-peer distributed system (also known as an embedded cluster) is the building block for
all vFabric SQLFire installations. With an embedded cluster, the core SQLFire engine is embedded alongside
an existing Java application in the same JVM. When the application initiates a connection to SQLFire using the
peer JDBC driver, it starts a SQLFire peer member that joins other peers in the same cluster.
• Understanding Embedded Peer-to-Peer Deployment on page 214
• Deciding When to Use Embedded Peer-to-Peer on page 214
• Example Code for Embedding SQLFire Members on page 215
Understanding Embedded Peer-to-Peer Deployment
The embedded peer-to-peer model provides embedded Java applications with default one-hop or no-hop access
to data. Each peer member communicates directly with the other members of the cluster and can host data as
necessary, persist data to disk (if it is a data store), and participate in distributed queries. All peers are treated as
"fully authorized" by the SQLFire security framework after they are authenticated.
An embedded SQLFire peer can optionally provide network server functionality for applications that need to
support connectivity from JDBC or ADO.NET clients. Or, you can embed SQLFire in a cluster of application
servers such as Apache Tomcat or Oracle WebLogic, which provide their own network server functionality. A
single attribute in the JDBC peer driver connection determines whether the SQLFire peer also provides network
services.
Embedding SQLFire peer services is supported only for Java applications. Existing Java applications can easily
switch to using an embedded SQLFire peer by including the required SQLFire libraries and specifying the
SQLFire JDBC peer client URL.
Note: In this release of SQLFire, ADO.NET clients cannot connect as peers.
Deciding When to Use Embedded Peer-to-Peer
Here are typical scenarios in which you would use the embedded peer-to-peer model:
• Many applications frequently accessing content directly from within the process heap (for example,
session state data or other Web content). The embedded peer-to-peer model automatically provides one-hop
or no-hop access to data. The SQLFire JDBC thin-client driver also supports one-hop access for lightweight
client applications.
• More convenient from an administration and management standpoint. With an embedded cluster, there
is no need to manage any external processes in order to deploy SQLFire peers. For example, if you embed
SQLFire in a cluster of Java application servers, each application server and the associated SQLFire peer share
the same process heap.
• Applications requiring a few peer clients (as opposed to hundreds). Deploying many peers increases the
buffering and socket overhead for each member. Having numerous peers can also strain the group membership
system coordinator, and it increases the overhead necessary for detecting failures. In an embedded cluster
deployment, all SQLFire transactions and distributed locks are maintained by the peers themselves. This is in
contrast to the client-server deployment model, in which clients are required to execute server-side code (such
as stored procedures) in order to acquire locks or execute transactions.
• Partitioned caching applications in which a small number of "feed" clients push data to an RDBMS at
a very fast rate.This scenario is particularly suited to embedded peer-to-peer. SQLFire peer members dispatch
messages to other peers synchronously by default, and with minimal context-switching. This provides the
lowest possible latency and offers the highest distribution throughput for both replicated caching as well as
partitioned caching applications. It also offers the lowest distribution latency, which useful for latency-sensitive
"feed" clients.
vFabric SQLFire User's Guide214
Deploying vFabric SQLFire