Quote:
1) No concurrent database write accesses. |
You will likely need to use locking if there are readers and
writers accessing the database at the same time. In other
words, if there are multiple threads of control accessing the
database concurrently, and any of those threads are modifying
the database, you will likely need to use locking.
Quote:
Currently the code is working fine, but checkpointing can be a slow
process (2-3 seconds, or more) and I would like to be able to do
periodic checkpoints in a separate thread/process.
Can I do that safety even if the database doesn't use the DB_INIT_LOCK
flags?. I think so, but I would like to be sure. |
Yes, checkpointing is done outside of the Berkeley DB logical
locking implementation, and does not require DB_INIT_LOCK.
Quote:
Can I safety use "read-only" berkeleydb tools, like "db_stat" or
"db_checkpoint" from the command line, in a such lock-unprotected
enviroment?. |
No; the read-only tools will potentially see database pages in
inconsistent states if they access the database while there is
a thread of control updating the database. The read-only tool
may return incorrect or inconsistent data if that happens, or
simply drop core.
Regards,
--keith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic
Oracle Corporation
keith.bostic (AT) oracle (DOT) com
keithbosticim (Yahoo IM)