hi all,

my application is self deadlocked while trying to update data during a
cursor traversal.
the cursor is holding a read lock on the resource which cause my write
operation to block.
it is very common in my application to update data according to
traversed data, for example:
iterating over the 'persons' table and update some records in it
according to some other recods.

the current design does'nt allow me to update the records through the
cursor.
i "solved" it the following manner:
1. open a cursor and read the data from the table to a vector.
2. close the cursor.
3. iterate on this vector and update the table according to it.

as you can see its a very dirty and expensive solution.

what would you recommend me to do?

another thing,
in the documentation it is mentioned that the locks are held over
"pages".
i dont understand what pages are. tables? records? where can i read
about it?

thanks,
moshe.

Use Transactions.

I would recommend having all read/update activity for a group of
related records to be part of the same transaction ID. That should
avoid any locking problems as long as you pass the same txnid in the
API calls. For more information:

http://www.sleepycat.com/docs/ref/transapp/intro.html

http://www.sleepycat.com/docs/api_c/txn_list.html

The Reference Guide will also discuss your other questions (pages,
records, tables).

Ron

Thank you ron.

as far as i can remember, we already tried to use transactions.
i'll check again if we did something wrong (maybe we opened the cursor
without passing the transaction).

if i dont want to use transactions then the way i solved the problem is
the only way to do it?

About the pages,
im afraid you didnt understand my question.
i know what tables and records are but im not familiar with the concept
of pages.
what exactly is a page? a group of records? one record? the whole
table?
if the lock is on pages than how can i control the size of the page?
does it mean that the smaller the pages are the less locks will i have?

can you refer me to the section in the manual which explains it?

thank you again,
moshe.

moshe wrote:
I think you have three choices:
1) use a transaction and perform all the operations 'in' that txn
2) perform all the operations using a single cursor,
3) use multiple cursors, but create all but the first using
DBC->c_dup() so that they all share the same locker id

These all have limitations of sorts.

Choice (1) may require major application changes, as transactions are
an all or nothing affair: you can only perform transactional updates on
tables that were opened inside a transaction and such tables cannot be
updated without using transactions (though DB_AUTO_COMMIT can hide the
txn in some cases).

Meanwhile, choices (2) and (3) may be impossible depending on the
operations involved. While most DB operations can be performed (or
emulated) using a cursor, there are several that can't. The obvious
ones are calls like DBENV->dbrename() and DB->truncate(), but it's also
true of DB->put(..., DB_APPEND). So, if your updates include those
sorts of operations, you'll have to use transactions.


Pages are a 'physical' level concept and are independent of records. A
file is typically treated as an ordered set of pages, all of the same
size. For example, if you're using pages of 8KB, then bytes 0 to 8191
are the first page, bytes 8192 to 16383 are the second page, etc. The
DB library stores records on pages, splitting them across pages in some
cases. How it does that is an internal detail of the DB library and
subject to change by Sleepycat between versions.


The references listed in the "Additional References" section of the DB
reference guide would be a good place to start.


Philip Guenther