Handling Conflicts of Automatic/Manual Update Propagation

The time spent in Update Propagation depends on a number of factors. As a simple rule of thumb, it could be considered as LINEAR to the size of the underlying table. While partial update propagation (COMBINE) can avoid rewriting all the data in a table (see full_rewrite_on_update_propagation below), it always has to read the whole table.

A COMBINE flushing just one MB of updates on one TB table will not be much faster than combine flushing five GB of updates on the same table.

Conflicts may occur:

• Between Append and COMBINE or (automatic) Update Propagation

• Between manual COMBINE and updates

Note: If the automatic Update Propagation fails on the same table for 3 times (seemax_number_propagate_retries below), Vector will NOT try to trigger it again until the next x100 server restart. However, the counter resets after ANY successful Update Propagation on ANY table in the database.

For example, if Update Propagation fails constantly on table BIG, but it succeeds on tableSMALL from time to time, the counter resets (also for BIG) and Update Propagation is tried again as long as the threshold triggers.

Generally the automatic Update Propagation does not CONFLICT with DML operations (Insert/Modify/ Delete in terms of x100 algebra). It does conflict with Append though. Typically an automatic (background) Update Propagation is INTERRUPTED by an incoming Append operation.

Regular transactions conflict on COMMIT due to the optimistic concurrency control model Vector is using (for details refer to the Transaction Isolation Level section of the Vector User Guide - for 2016.1, refer to the Vector 4.2 guide; for 2018.0 and later, refer to Vector 5.0 guide).

There is a tiny window when Append might fail to INTERRUPT an Update Propagation. In that case one of the operations will be rejected when committing.

Manual COMBINE may well CONFLICT with updates and appends. In both cases the COMBINE operation is not interrupted. Instead it is REJECTED on COMMIT.

Unlike the automatic (background) Update Propagation, manual COMBINE does not have the special mechanism that reconciles updates with Update Propagation, which is essentially a COMBINE but executed automatically by the database x100 server.

Note:

• A manual COMBINE is treated like Append because it is triggered by a user and can be mixed with other statements in a single transaction. It can CONFLICT with DMLoperations during COMMIT.

• Update Propagation is automatic, triggered at certain thresholds and can get interrupted only by Appends.

The following concurrency / compatibility table illustrates possible conflict / interruption operations: