IE> If you do it at the application level within a transaction (even if
IE> it did fit in memory) you would either implicitly halt all activity or
IE> constantly be aborted by any write operation anywhere in the db.
ah, indeed, this way bdb works.. PostgreSQL uses MVCC by default, so reading
activity doesn't block writting.
documentation says you can also get MVCC in bdb via "snapshot isolation" --
it would implement copy-on-write on database level.
see here:
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/read.html
http://www.oracle.com/technology/documentation/berkeley-db/db/api_cxx/txn_begin.html
DB_TXN_SNAPSHOT
This transaction will execute with snapshot isolation. For databases with
the DB_MULTIVERSION flag set, data values will be read as they are when the
transaction begins, without taking read locks. Silently ignored for
operations on databases with DB_MULTIVERSION not set on the underlying
database (read locks are acquired).
or that's what you meant when said "Implement a copy-on-write policy in
your transactions"?
IE> Berkeley DB also supports low-level hot backups if you know that your
IE> OS reads file pages atomically.
IE> (http://www.oracle.com/technology/documentation/berkeley-db/db/ref/tran
IE> sapp/archival.html ) For an example see the source code for
IE> db_hotbackup in the BDB distribution.
that's probably preffered way indeed.
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
