- *
- * A brief technical discussion:
- *
- * Several of the purge operations found in this module operate in two
- * stages: the first stage generates a linked list of objects to be deleted,
- * then the second stage deletes all listed objects from the database.
- *
- * At first glance this may seem cumbersome and unnecessary. The reason it is
- * implemented in this way is because Berkeley DB, and possibly other backends
- * we may hook into in the future, explicitly do _not_ support the deletion of
- * records from a file while the file is being traversed. The delete operation
- * will succeed, but the traversal is not guaranteed to visit every object if
- * this is done. Therefore we utilize the two-stage purge.
- *
- * When using Berkeley DB, there's another reason for the two-phase purge: we
- * don't want the entire thing being done as one huge transaction.
- *
- * You'll also notice that we build the in-memory list of records to be deleted
- * sometimes with a linked list and sometimes with a hash table. There is no
- * reason for this aside from the fact that the linked list ones were written
- * before we had the hash table library available.