1.1

with certain consistency guarantees. Each member in the group participates in membership decisions, which
ensures that either all members see a new member or no members see it.
The membership coordinator, a key component of the GMS, handles "join" and "leave" requests, and also handles
members that are suspected of having left the system. The system automatically elects the oldest member of the
distributed system to act as the coordinator, and it elects a new one if the member fails or is unreachable. The
coordinator's basic purpose is to relay the current membership view to each member of the distributed system
and to ensure the consistency of the view at all times.
Because the SQLFire distributed system is dynamic, you can add or remove members in a very short time period.
This makes it easy to reconfigure the system to handle added demand (load).The GMS permits the distributed
system to progress under conditions in which a statically-defined membership system could not. A static model
defines members by host and identity, which makes it difficult to add or remove members in an active distributed
system. The system would have to shut down partially or completely to expand or contract the number of members
that participate in the system.
For more information, see:
• Start and Stop SQLFire Servers Using sqlf on page 223
• Connect to a Distributed System Using Locators on page 221
• Rebalancing Partitioned Data on SQLFire Members on page 66
Replicated Tables and Partitioned Tables
Tables in SQLFire can be partitioned or replicated. A replicated table keeps a copy of its entire data set locally
on every SQLFire server in its server group. A partitioned table manages large volumes of data by partitioning
it into manageable chunks and distributing those chunks across all members in the table's server group.
By default, all tables are replicated unless you specify partitioning in the CREATE TABLE statement. The
schema information for all SQLFire objects is visible at all times to all peer members of the distributed system
including peer clients, but excluding standalone locators.
Partitioning Tables on page 59 and Replicating Tables on page 69 provide more information.
Parallel Execution of Data-Aware Stored Procedures
In a traditional relational database, stored procedures are application routines that are stored as part of the data
dictionary and executed on the database system itself. Stored procedures generally offer high performance
because they execute in close proximity to data required by the application logic. SQLFire extends this basic
stored procedure capability to support parallel execution of application logic on table data that is partitioned
across many peers.
SQLFire applications can execute stored procedures on specific data hosts, in parallel on all the members of a
server group, or can target specific members based on the data requirements for the procedure. Essentially,
application behavior that is encapsulated in stored procedures is moved to the process that hosts the associated
data set, and it is executed there. If the required data set is spread across multiple partitions, the procedure is
executed in parallel on the partition members. Results are streamed to a coordinating member and aggregated
for the client invoking the procedure.
For example, consider an 'Order' table that is partitioned by its 'customer_id', and an application wanting to
execute an expensive 'credit check' for several customers. Assume the credit test requires iteration over all the
order history. You can parallelize the execution on all members that manage data for these customers and stream
the results to the client. All order history required by each execution is locally available in-process.
// typical procedure call
CallableStatement callableStmt = connection.prepareCall("{CALL
order_credit_check(?) ");
callableStmt.setArray(1, <list of customer IDs>);
13
Understanding the SQLFire Distributed System