No Ordering Guarantee for DML in Separate Threads

GemFire XD 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, GemFire XD 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 GemFire XD 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.