What I noticed
I set out to configure bi-directional replication in Connect CDC and immediately hit a wall of restrictions around TPT. Not every constraint was obvious. Some of them quietly change how your data lands on the target.
Bi-directional replication is supported in Connect CDC (MIMIX Share) but not across all DBMS platforms. MS SQL Server CDC does not support it at all. Once I confirmed the platform, TPT brought its own rules:
- Precisely only supports certified TPT version 14.10.14.
- TPT is supported on Windows and UNIX.
- Large objects (LOB) are not supported.
- Row operation order across source transactions is not guaranteed at the target but order within any mapped table is preserved.
- All updates are handled as deletes followed by inserts to protect the primary index and simplify TPT scripts.
- Updates use all values of the before and after image of mapped columns due to TPT scripting language limitations.
- TPT is not allowed as part of a Synchronization request.
- Create table privileges are required by the replicating user.
- TPT log files must be manually cleaned up after jobs run.
- File system replication restrictions also apply.
Two more rules shape bi-directional behavior: transaction bundling cannot be used for bi-directional mapping, and shadow table collision resolution is designed specifically for it. Two Replication requests for the same source table cannot be active simultaneously.
None of this is accidental. Every restriction maps to a deliberate design choice.
Why this design works
- Predictability: Certifying one TPT version and defining ordering and update semantics explicitly means apply behavior is known before a single row moves.
- Reliability: Delete-plus-insert for updates and shadow table collision resolution give stable, repeatable behavior during index-sensitive operations and conflicts.
- Operational Safety: Blocking TPT in synchronization, disabling bundling in bi-directional mappings, and preventing concurrent requests on the same table remove non-deterministic apply paths.
What's different for MS SQL Server / Bundling / Collision Resolution
There is one extra step.
- MS SQL Server CDC does not support bi-directional replication the platform is out before TPT even matters.
- Transaction Bundling cannot be used for bi-directional mapping - it is not a setting to turn off, it simply cannot apply here.
- Shadow table collision resolution is the mechanism built for bi-directional replication - design around it, not past it.
Why this matters in production
These rules decide whether the design holds under real load or breaks quietly.
If I am using TPT, I plan for delete-plus-insert updates. I exclude LOBs. I confirm create table privileges. I schedule log cleanup. I set expectations on cross-table ordering. I build collision handling around shadow tables. I never run two concurrent Replication requests on the same source table.
If you ever see updates arrive as a delete followed by an insert, it is not random. It is Connect CDC doing exactly what it should.
What changed for me
I used to assume bi-directional meant it just mirrors, regardless of platform or loader. I now treat TPT restrictions as design inputs, not surprises. The delete-plus-insert pattern and the ordering guarantees make the apply path predictable. Leaning on shadow table collision resolution and removing bundling from the picture reduces operational risk. The model behaves better when I work inside the boundaries, not against them.
Takeaway
Bi-directional replication in Connect CDC is real, but the platform and loader choices set the limits. TPT changes update semantics, ordering expectations, and operational tasks. Align the design to those constraints including bundling, collision resolution, and request concurrency and the behavior is exactly as documented.
Have you run into TPT's update or ordering rules in a bi-directional setup? How did you adjust your design or operations to work within them?
------------------------------
Adhitya Maya
*Precisely Software Inc.
------------------------------