As part of SERVER-99150 we've implemented a lock ordering conflict detector.

During yields we save and restore the lock state, this poses a particular problem for operations that hold multiple acquisitions/autogetters on different databases. This is because the locks taken due to the hierarchy for the databases may be in any ordering during a restore.

Take the following example:

• We acquire collA on dbA
• We acquire collB on dbB.

At this point the lock ordering followed is dbA -> collA -> dbB -> collB.

However, during a yield the following lock ordering can take place when we restore if the resourceId of dbA is < dbB:

• Lock dbA
• Lock dbB
• Lock collA
• Lock collB

Today this isn't a problem since we have no operations that yield and restore with multiple databases as aggregations hold their locks internally and thus aren't susceptible to normal yields. We should still however, consider how we can tackle this ordering issue during yields.