Currently, if the database becomes inaccessible subsequent to the initial successful connection, replicator will log failures to complete operations, but unless the "stop on error" option is being used, will continue to process. This can results in changes not being applied to the database.
We should modify replicator such that if this type of database error is encountered, it attempts to close any open cursors, disconnects from the database, and then attempts to re-connect. This process should occur periodically for some period of time, perhaps waiting up to 24 hours before finally giving up and stopping.
This change would allow the replicator to be resilient to the database being taken off-line for management purposes, without losing any changes that occurred while the database was off-line.
Currently, if the database becomes inaccessible subsequent to the initial successful connection, replicator will log failures to complete operations, but unless the "stop on error" option is being used, will continue to process. This can results in changes not being applied to the database.
We should modify replicator such that if this type of database error is encountered, it attempts to close any open cursors, disconnects from the database, and then attempts to re-connect. This process should occur periodically for some period of time, perhaps waiting up to 24 hours before finally giving up and stopping.
This change would allow the replicator to be resilient to the database being taken off-line for management purposes, without losing any changes that occurred while the database was off-line.