I've a single threaded application which updates my Berkeley DB in a single transaction. My operations look like below:
Inside this single thread of control, there can be huge number of db updates (there can be 5 million or even more updates).
I had set the set_lk_max_lockers value in DB_CONFIG pretty high. But few times, the application was hit by "no more locks available" error.
To overcome this, I set these values in DB_CONFIG pretty high. Now my DB_CONFIG values are as shown below:
But with this the new problem is size of my one of the __db* files is huge (of the order of 8-10 GB).
Now in this release I'm not planning to make my application multi threaded. The application will have single thread of control for BDB.
Then do I've an option to set set_lk_max_locks* values to default and to open the db in exclusive lock mode using set_lk_exclusive() function?
Kindly help me to figure out will the above setting solve my problems of maximum locks value and the resulting __db* file size?
~ Ashish K.
I've BDB 5.1 version.
But looks like function set_lk_exclusive is not supported.
When I use the above function, I get below error:
"DB has no member named set_lk_exclusive"
Is this a deprecated function? What is the api to achieve the same functionality in DB 5.1?
~ Ashish K.
The DB->set_lk_exclusive function is a new function introduced in db-5.3, and you can see the upgrade guide at http://docs.oracle.com/cd/E17076_03/html/installation/upgrade_11gr2_53_excl.html
So, it is not available in db-5.1.
If your program has only single thread of control(no multi-threads and no multi-process) access to BDB, you can even turn off lock by not providing DB_INIT_LOCK when creating the environment, since DB_INIT_LOCK is not required to occur with DB_INIT_TXN.
Turning off lock and turning on txn can give you the assurance of atomicity and durability. And you need to make sure no concurrent access to ensure consistency and isolation.
Another way is to re-structure your program avoid doing so many updates in a transaction and distributes the updates into multiple transactions, and start next after previous commits. But this depends on your program logic, so we can not give further suggestions about how to divide the operations without getting more information.