Hi,

I have multiple databases in a single file. In one transaction, I am
updating some of those databases and in another I am opening a
different database though one in the same file. I am doing this in a
single thread and am getting a self deadlock because it appears that
the databases overlap on a page in the file. A snippet from db_stat
shows this:

800007e8 WRITE 1 HELD
/home/lohorealty/www/repository/envs/staging/var/objectAboutPageSection
page 0
800007f4 READ 1 WAIT
/home/lohorealty/www/repository/envs/staging/var/objectAboutPageSection
page 0

The database open reports "12 lockers" and then hangs until a timeout
passes and the transactions are rolled back. So, is there a way to
prevent separate database in the same file from sharing pages? Or am I
interpreting what I am seeing incorrectly?

Thanks for the help,
Mike

P.S. Sleepycat Software: Berkeley DB 4.3.28: (April 22, 2005)

I found a similar problem reported here:

http://groups.google.com/group/comp....97c07bb6f5b3a6

So from what I understand, page 0 contains the metadata for all the
databases in the file. So under the circumstance that this metadata is
changed in one transaction, opening any database in the same file in
another transaction will block trying to get a read lock on page 0
until that first transaction is completed. I was able to change my
application to avoid this seld deadlock. There is a brief mention of
this issue in the "Opening multiple databases in a single file" section
of the reference manual too though I have to admit I read it a few
times and didn't really understand the ramifications until I saw the
Michael Ubell's posting referenced above.

Thanks for a great product,
Mike

mab <barborak (AT) mode20 (DOT) com> writes:
As a rule of thumb, no single thread of control should have multiple
independent lockers in use at any given time. If a thread does so and
one of the lockers blocks another, the DB library cannot tell that a
deadlock has occured: it doesn't know that the blocking locker won't be
moved forward in another thread or process. Yes, you _may_ be able to
get away with this in particular circumstances, but doing so a fragile
design.

Since independent transactions are independent lockers, having two
transactions open in a single thread is only safe if one is a child
transaction of the other, as the locks held by a parent won't block the
child. Note that even working in two sibling transactions can result in
self deadlock, as siblings _do_ conflict with each other.

This is described in the Sleepycat Programmer's manual, chapter 14 (The
Locking Subsystem), section 12 (Berkeley DB Transactional Data Store
locking conventions). Note particularly the paragraph that starts "This
has important implications."


So, there are three solutions:
1) do all the operations in a single transaction,
2) commit or abort the pending transaction before starting a new one, or
3) put the transactions in different threads.

Which choice is best for your application depends on why you're using
transactions they way you currently are.


Philip Guenther

Thanks for the reply and that make perfect sense. For posterity, my
problem arose because I was opening my databases with DB_AUTO_COMMIT
rather than with any ongoing transaction. The solution then was to look
for an ongoing transaction and use it instead during the open.

Thanks,
Mike