Why does Shareplex lock the source tables when removing them from replication? (4300578)

When trying to remove a table from replication activate config fails with error:

Unable to lock "USER"."TABLE", it is currently involved in a transaction.

There is an open oracle transaction on this table that is preventing shareplex from locking the table for removal purposes

Shareplex will always check for any open transaction on a table that is currently being removed from replication. This is to ensure that no DML in the queue belongs to a table that is not a part of replication. To ascertain this, it tries to acquire lock on that table. At times it is not able to acquire such lock and the activation to remove the table from replication fails. So if the table fails to be removed from replication because it cannot be locked, please wait and retry the command at a later time.

If this logic was not built in it, then there could be issues as some DML pertaining to the problem table may be captured from the remaining part of the open transaction as and when they occur. However, the table would have been removed from replication in the sense that the object cache would be updated (on both source and target) so that the table would not form part of the object cache and the Shareplex internal tables would be updated to remove references to that table. This would cause issues with Post as and when the remaining part of the open transaction completes. To avoid all these complications, Shareplex will only allow a table to be removed from replication when there are no more open transactions pertaining to that table.

This phenomenon is also known as leftover fragments (incomplete transactions) in the queue.