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:
SERVER-5101 for an example of the dbtemprelease destructor assertion.