m4_comment([$Id: notxn.so,v 10.15 2001/05/22 19:39:31 bostic Exp $])m4_ref_title(Locking Subsystem,    Locking without transactions,    @locking without transactions, lock/page, lock/twopl)m4_p([dnlIf an application runs with locking specified, but not transactions (forexample, m4_ref(dbenv_open) is called with m4_ref(DB_INIT_LOCK) orm4_ref(DB_INIT_CDB) specified, but not m4_ref(DB_INIT_TXN)), locks arenormally acquired during each m4_db operation and released before theoperation returns to the caller.  The only exception is in the case ofcursor operations.  Cursors identify a particular position in a file.For this reason, cursors must retain read locks across cursor calls tomake sure that the position is uniquely identifiable during a subsequentcursor call, and so that an operation using m4_ref(DB_CURRENT) willalways refer to the same record as a previous cursor call.  These cursorlocks cannot be released until the cursor is either repositioned and anew cursor lock established (for example, using the m4_ref(DB_NEXT)or m4_ref(DB_SET) flags), or the cursor is closed.  As a result,application writers are encouraged to close cursors as soon aspossible.])m4_p([dnlIt is important to realize that concurrent applications that use lockingmust ensure that two concurrent threads do not block each other.However, because Btree and Hash access method page splits can occur atany time, there is virtually no way to guarantee that an applicationthat writes the database cannot deadlock.  Applications running withoutthe protection of transactions may deadlock, and can leave the databasein an inconsistent state when they do so.  Applications that needconcurrent access, but not transactions, are more safely implementedusing the m4_cam Product.])m4_page_footer