-
Bug
-
Resolution: Duplicate
-
Critical
-
None
-
2.3.4.Final, 2.4.0.Final
-
None
-
False
-
None
-
False
-
-
When enabling LOB support within the Oracle connector, there are use cases where the TransactionCommitConsumer will immediately dispatch a row when no LOB columns are detected and this will cause the events to be dispatched out of chronological order.
This regression was introduced by DBZ-6107.
Given use case:
connection.executeWithoutCommitting("INSERT INTO addresses (ID,PERSON_ID) values (" + i + ",-1)"); // i addresses accum=null connection.executeWithoutCommitting("UPDATE email SET person_id = " + i + " WHERE id = -1"); // -1 email accum=null connection.executeWithoutCommitting("INSERT INTO email (ID,PERSON_ID) values (" + i + ",-1)"); // i email accum=null connection.executeWithoutCommitting("UPDATE email SET person_id = " + (i + 999) + " WHERE id = " + i); // i email (Folded) accum has value connection.executeWithoutCommitting("UPDATE email SET person_id = " + (i + 1000) + " WHERE id = -1"); // -1 email accum has value, EMAIL has no LOB columns - so released connection.executeWithoutCommitting("UPDATE phone SET person_id = " + i + " WHERE id = -1"); // -1 phone accum=null connection.executeWithoutCommitting("INSERT INTO phone (ID,PERSON_ID) values (" + i + ",-1)"); // i phone accum=null connection.executeWithoutCommitting("UPDATE phone SET person_id = " + i + " WHERE id = " + i); // i phone (Folded) accum has value connection.executeWithoutCommitting("UPDATE phone SET person_id = -1 WHERE id = -1"); // -1 phone accum has value, PHONE has no LOB columns - so released connection.executeWithoutCommitting("UPDATE addresses SET person_id = " + i + " WHERE id = -1"); // -1 addresses accum=null
We can see there are two situations where the AccumulatorEvent has a value but the consumer immediately dispatches the events. This leads to a chronological order problem:
// UPDATE 7558821 PHONE (RELEASED) // UPDATE 7558818 EMAIL (RELEASED) // INSERT 7558815 ADDRESSES // INSERT 7558818 EMAIL // UPDATE 7558818 EMAIL // INSERT 7558821 PHONE // UPDATE 7558821 PHONE // UPDATE 7558825 ADDRESSES
In addition, none of these tables have LOB columns, so technically the outcome should be 10 events, not 8 as well.
- is caused by
-
DBZ-6107 When using LOB support, an UPDATE against multiple rows can lead to inconsistent event data
- Closed