Question about using Db cursors safely outside a transaction

Question

I have a question re: proper use of the Dbc (Db cursor) to avoid
self-deadlock when two cursors are opened by the same thread and used only
for reading. (This is when open in full transactional mode, with an
environment and all.)
My first question is, should I bother? Or is it equivalent to always start a
transaction, even before read operations? My reading of the doc says it is
not equivalent. The doc says "in the presence of transactions all locks are
held until commit". I read it as saying that reading with a cursor outside a
transaction provides degree 2 isolation (cursor stability), with greater
concurrency than reading inside a transaction (which provides degree 3
isolation). What I'm attempting here is to avoid degree 3 isolation, and
locks held until commit, for cursor reads -- I want the greater concurrency.
This is just a technique to do reading outside a transaction, all writing
will be done within transactions, and all reading will be done with a txnid
too, whenever a transaction is in progress. Am I OK so far?
Here's how I imagine getting away with it. Tell me if this works please :-)
and (of course) if there's a better way. Suppose DB_THREAD was specified,
but to avoid the dreaded self-deadlock when using multiple cursors outside a
transaction, all such cursors are used only to read and are dup'ed from a
single cursor (one kept as a prototype in each thread for that purpose,
solely to ensure a single locker ID for all these read cursors; the
prototype cursor is never used to lock anything). As I read the doc, that
prevents the thread from self-deadlocking, provided it doesn't start any
transactions while such read cursors are extant (other than the prototype
cursor, which shouldn't matter because it never holds any locks). I
understand that if the same thread did start a transaction, it could
self-deadlock with such a read cursor, but I won't be doing that.
My next question is, am I still OK if multiple Db's are placed in one file?
The doc says in that case lock contention can only occur for page
allocations -- seeming to imply that competition among read-only cursors
won't ever cause it -- though they could be contending with other threads
that are writing -- could thread self-deadlock ever occur here? I'm not
worried about real deadlock with the other (writer) thread, just thread
self-deadlock between my two read cursors.
Many thanks if you could confirm my reasoning (or dash my hopes) before I
find out the long, hard nondeterministic way if it's any good.

Answer 1

Good, so I've overdesigned my solution -- I can dispense with dup()ing a prototype cursor and just use multiple read-only cursors made by Db::cursor with a NULL txnid.
Many thanks for your prompt response.
I am David Christie at samizdat.org BTW -- we exchanged email last year re: a potential C++ std container interface for Berkeley DB -- sometime before the merger. I hope it's all worked out well for your sleepycat guys. It's nice to see some of you are still around and responding to the open source community.