| Description | When sending a multi-table load with datareload.batch.insert.transactional=false and create_table=1, it's possible for the row in sym_table_reload_status to have incorrect values for data_batch_loaded and finalize_batch_loaded.
When datareload.batch.insert.transactional=false, the extract requests that are a part of a load get committed separately. When an extract request is complete and create_table=1, SymmetricDS inserts a create event into sym_data which will result in a finalize batch being created for the purpose of applying the deferred constraints to the target table. If an extract request completes before all of the other extract requests have been committed, a finalize batch will be created with a batch_id that is lower than the batch_id(s) associated with the uncommitted extract request(s). SymmetricDS appropriately increments the end_data_batch_id of the row in sym_table_reload_status to account for any early finalize batches, but when setting the values for data_batch_loaded and finalize_batch_loaded, it considers these early finalize batches to be data batches because their batch_id(s) fall between the start_data_batch_id and end_data_batch_id. As a result, the data_batch_loaded value will be higher than it should be and the finalize_batch_loaded value will be lower than it should be. Because the finalize_batch_loaded value never reaches the finalize_batch_count, the completed flag never gets set. |
|---|