M> that sounds like the key for this specific mismatch of the BDB locking
M> philosophy – which for the scenarios you describe is perfect – and our
M> quite different needs.
there is other sort of locking philosophy in BDB too -- so-called "snapshot
isolation"
(also known as multi-version concurrency control). check this:
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/read.html
----
Snapshot isolation also guarantees repeatable reads, but avoids read locks
by using multiversion concurrency control (MVCC). This makes update
operations more expensive, because they have to allocate space for new
versions of pages in cache and make copies, but avoiding read locks can
significantly increase throughput for many applications. Snapshot isolation
is discussed in detail below.
If the cache becomes full of page copies before the old copies can be
discarded, additional I/O will occur as pages are written to temporary
"freezer" files.
----
so it seems if you use snapshot isolation, you won't have "cannot allocate
memory', but if cache is too small performance will be degraded due to
additional I/O.
but i haven't used it myself, so i dunno if it's really so.
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
