Issue 729889 mentions that dbm access relies on a global tracker lock. In issue 2551036
on rest rate limiting, I mention a 10% non-record rate possibly caused by failure
to get a lock or other issue.

So it seems we have a performance issue with DBM. SQLite used to be used for sessions/otks
db's. However there is only one handle to the database. So flushing CSRF keys when used
caused data to commit when it shouldn't have (issue2550955). On MySQL/PostgreSQL opening
a second connection to the db for session/otks soved the issue. That's not possible with
SQLite. At that point, session_dbm was paired with back_sqlite to handle the otks/sessions
database.

I have a working implementation (its passing the test suite) that uses sqlite
databases db-otk and db-session for the respective storage.

Will be testing for performance issues on my system.
Working on improving the sessions test suite but that will be the subject of 
issue2551223.