1.0

the application ecosystem is typically dealing with many distributed processes and applications, most of which
are not designed to cope with partitioning problems.
By offering a very loosely coupled WAN replication scheme, SQLFire enables the entire client load to be shifted
to an alternate "disaster recovery" site.
No Ordering Guarantee for DML in Separate Threads
SQLFire preserves the order of DML statements applied to the distributed system (and queued to
AsyncEventlisteners or remote WAN sites) only for a single thread of execution. Updates from multiple threads
are preserved in first-in, first-out (FIFO) order. Otherwise, SQLFire provides no "total ordering" guarantees.
Data inconsistency can occur if multiple threads concurrently update the same rows of a replicated table, or if
threads concurrently update related rows from replicated tables in a parent-child relationship. Concurrently
updating the same row in a replicated table can result in some replicas having different values from other replicas.
Concurrently deleting a row in a parent table and inserting a row in a child table can result in orphaned rows.
When DML operations are queued to an AsyncEventListener or remote WAN site, similar inconsistency problems
can occur with concurrent table access. For example, if two separate threads concurrently update rows on a
parent table and child table, respectively, the order in which SQLFire queues those updates to an
AsyncEventListener or WAN gateway may not match the order in which the tables were updated in the main
distributed system. This can cause a foreign key constraint violation in a backend database (for example, when
using DBSynchronizer) or in a remote WAN system that does not occur when the tables are initially updated.
These types of "out of order" updates do not occur when multiple threads concurrently update the same key of
a partitioned table. However, an application should always use a transaction for any operation that updates
multiple rows.
Updates on Any Row Are Atomic and Isolated
When rows are updated members may receive a partial row. SQLFire always clones the existing row, applies
the update (changes one or more fields) and then atomically replaces the row with the updated row. This ensures
that all concurrent threads reading or writing that row are always guaranteed to be isolated from access to any
partial row updates.
Atomicity for Bulk Updates
SQLFire does not validate all constraints for all affected rows before applying a bulk update (a single DML
statement that updates or inserts multiple rows). The design is optimized for applications where such violations
are rare.
A constraint violation exception that is thrown during a bulk update operation does not indicate which row of
the bulk update caused a violation. Applications that receive such an exception cannot determine whether any
rows in the bulk operation updated successfully.
To address the possibility of constraint violations, an application should apply the bulk update within the scope
of a transaction, which ensures that all rows are updated or rolled back as a unit. As an alternative, the application
should select rows for updating based on primary keys, and apply updates one at a time.
vFabric SQLFire User's Guide136
Developing Applications with SQLFire