Commit eb65b11c authored by Jelte Jansen's avatar Jelte Jansen
Browse files

[2541] Catch and log exception in transaction rollback

parent 5c72873a
......@@ -55,7 +55,18 @@ public:
~TransactionHolder() {
if (!committed_) {
try {
} catch (const DataSourceError& e) {
// We generally expect that rollback always succeeds, and
// it should in fact succeed in a way we execute it. But
// as the public API allows rollback() to fail and
// throw, we should expect it. Obviously we cannot re-throw
// it. The best we can do is to log it as a critical error.
void commit() {
......@@ -186,8 +186,8 @@ public:
/// responsibility of the caller to do so.
/// Callers must also start a transaction before calling this method,
/// implementations may throw DataSourceError if this has not been done.
/// Callers should also expect DataSourceErrors for other potential
/// implementations should throw DataSourceError if this has not been
/// done. Callers should also expect DataSourceErrors for other potential
/// problems.
/// \param name The (fully qualified) domain name of the zone to add.
......@@ -1399,9 +1399,6 @@ public:
/// does not, creates it, commits, and returns true. If the zone
/// does exist already, it does nothing (except abort the transaction)
/// and returns false.
/// \param name The (fully qualified) name of the zone to create
/// \return True if the zone was added, false if it already existed
virtual bool createZone(const isc::dns::Name& name);
/// \brief Get the zone iterator
......@@ -216,6 +216,16 @@ to find any invalid data and fix it.
No match (not even a wildcard) was found in the named data source for the given
name/type/class in the data source.
% DATASRC_DATABASE_TRANSACTION_ROLLBACKFAIL failed to roll back transaction on %1: %2
A transaction on the database was rolled back without committing the
changes to the database, but the rollback itself unexpectedly fails.
The higher level implementation does not expect it to fail, so this means
either a serious operational error in the underlying data source (such as a
system failure of a database) or software bug in the underlying data source
implementation. In either case if this message is logged the administrator
should carefully examine the underlying data source to see what exactly
happens and whether the data is still valid.
% DATASRC_DATABASE_UPDATER_COMMIT updates committed for '%1/%2' on %3
Debug information. A set of updates to a zone has been successfully
committed to the corresponding database backend. The zone name,
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment