Currently dbtemprelease's destructor attempts to acquire the same lock type as was yielded and restore the thread's client context to its pre yield state. If the lock is a read lock and the context's namespace belongs to a database that was closed during the yield, restoring the context will fail and dbtemprelease's destructor will assert.

Asserting in dbtemprelease's destructor seems particularly unsafe because as a raii class its destructor is designed to be called when another exception is active.

There seems to be a way to detect an active stack unwinding exception in a destructor, but it may be unreliable and there is no way to replace this exception with a higher priority exception about an inability to recover the thread's client context.

Provisionally two options for dealing with this are:

• Implement a dbtemprelease with a destructor that cannot fail to restore state.
• If dbtemprelease can fail to restore state, it should not be implemented as an raii class but perhaps instead using exception forwarding, maybe something like:

  try {

  releaseState();

  doSomething();

  restoreState();

  } catch ( ... ) {

  restoreState(); // may throw

  throw;

  }

See SERVER-5101 for an example of the dbtemprelease destructor assertion.