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.

Question do we need a migration plan for the data from the dbm files to sqlite?
The session and otk data is ephemeral so I am inclined to not provide a way to migrate.

See: changeset:   6808:375d40a9e730

Sorry, previous msg pointed to wrong commit:

    changeset:   6804:25d08e15e3b4

is the right changeset.

The commit in the previous msg completed testing
on the BasicDatabase underlying otks/sessions.