}
~TransactionHolder() {
if (!committed_) {
- accessor_.rollback();
+ try {
+ accessor_.rollback();
+ } 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.
+ logger.error(DATASRC_DATABASE_TRANSACTION_ROLLBACKFAIL).
+ arg(accessor_.getDBName()).
+ arg(e.what());
+ }
}
}
void commit() {
/// 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.
/// 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
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,