There are several limitations to the
distribution by connection mode.
- Distribution by connection does not send transactions serially between
connections. A transaction on one connection may arrive at the replicate
database in a different order relative to adjacent transactions on another
connection compared to the transaction order in the primary database
log.
- Distribution by connection does not guarantee uniform transaction
distribution and load balance:
- RepAgent sender threads may fill up if large transactions fall
disproportionately on some senders.
- A RepAgent sender can be busy and still have transactions entering
the sender queue.
- The distribution by connection model
uses the SPID associated with a user or application session to distribute
replicated data across all paths. As long as the SPID associated with a user
session stays the same, all the transactions by that user or application
uses the same path. If the user or application directly connects to same
data server as RepAgent, the SPID does not change and there are no
transaction serialization issues.
However, if a user or application uses
a middle tier application server with a connection pool to execute
transactions on the data server that RepAgent connects to, the SPID used
to execute the transaction may change. For example, if an
insert transaction from a user is followed by an
update transaction to the same data, the
insert transaction may have a different SPID than
the update transaction. This situation can occur
because the middle tier application server may use different connections
to execute each transaction. In this situation, RepAgent sends the
update and insert on different
paths and a transaction serialization problem may occur if the
update arrives at the replicate database before
the insert.