Ajit,

I disagree with your perspective that Burst and Resilient are mutually exclusive.

Burst achieves a performance boost by using micro batches to process changes. In order to do this consistently - in a micro batch you cannot perform more than one change per row - the burst mode condenses (coalesces) multiple changes on the same row (based on the primary key) to a single change.

Resilient processing deals with potential discrepancies between presumed and actual state in the target table. Rather than stopping replication when there otherwise would be an error processing continues by applying an alternative operation. Resilient processing will:

- Insert a row for an update if the row to be updated does not exist
- Update a row for an insert if a row with such primary key already exists
- Ignore row deletes for rows that cannot be found

Whether such operations are performed based on coalesced operations is irrelevant.

The only scenario where burst processing is known to cause out-of-sync situations is when a table does not have a key, there are duplicate rows in the table, and a delete is processed. Burst processing will delete all rows in such case.

Except for the case mentioned Burst processing should not cause out of sync conditions. Resilient processing against an up to date data set should not result in out-of-sync conditions (i.e. Resilient has no effect if data is in sync). If it would - again, except for the mentioned scenario - then there would be a bug and not an enhancement.

In my opinion there is value in combining Resilient and Burst processing and I see no reason to make these options mutually exclusive.

Hope this clarifies and helps.
Mark.