This API is horrible in every way, and it'd be much better to close our collective eyes, pretend it doesn't exist, and never use it again.

That said, a cleaner fix would be to switch to std::recursive_mutex and note in the header/include files that Lock/Unlock calls may be nested and must be balanced.

Never heard of recursive_mutex until just now, neat.

But is that actually a better solution? The crash is caused when you misuse lock (i.e. extra call or missing unlock), so with recursive_mutex you're trading that UB-potential-crash for a more silent database-deadlock, right? Or am I missing something?
You'd lose track of how many recursions deep you are as opposed to my method which ignores redundant calls--so only a single unlock would be needed to fix the database state.

They both end up doing the same thing but my one is more recoverable from an invalid state, no?

The API should not be used, at all, ever. The best fix is to remove it.

And, why: it's fundamentally broken. One, it blocks the main thread, which is a no-no. Two, a native error, spurious or otherwise, could cause the database to become permanently locked. Neither of these are fixable.

So, IMO, deciding on the "right" behavior is moot, when there is a trivial workaround: having two database connections.

I think a similar thing needs to be done by separate PR/changes for User Messages (I was dealing with Protobuf).