ryan at efrus.com
Thu Jan 16 21:24:21 CET 2014
I don't have any experience with _DBWithCursor, and I haven't really done
extensive testing of my setup, so I'd be interested to know what you learn
about this use-case, as it's similar to mine. To allow multiple access, I'm
opening a dbenv with these flags:
db.DB_CREATE | db.DB_INIT_MPOOL | db.DB_INIT_TXN | db.DB_INIT_LOG |
And then adding the flag: db.DB_TXN_NOWAIT
For the db (btree type), I'm opening it with:
db.DB_AUTO_COMMIT | db.DB_CREATE | db.DB_MULTIVERSION
Then, I wrap all of my cursors in a transaction that is opened with the
This allows writing to the database when cursors are currently reading. I'm
sure this is not the fastest solution (in fact, maybe it's quite slow), but
it seems to be pretty flexible.
I'd be happy to hear of a faster/better way.
On Thu, Jan 16, 2014 at 11:07 AM, Matt Chaput <matt at whoosh.ca> wrote:
> Hi PyBSDDBers!
> I’m trying to use a BTree with single-writer/multi-reader transactional
> semantics: I want readers to see a snapshot of the moment they were opened,
> and changes made to writers to not be visible until they commit (and it’s
> OK if readers have to be re-opened).
> Just using bsddb3.btopen() *seems* to give me something very close to this
> automatically: if I open a “writer” and make changes, they aren’t visible
> in “readers” until the “writer” is closed and the “readers” are re-opened.
> However, the one thing this doesn’t seem to allow is aborting/rolling back
> the changes made in a writer.
> I tried using the bsddb.db API so I could use DBEnv.txn_begin() to get a
> transaction, but besides the code being harder to write, my test (writing
> just 50,000 keys) is *20x* slower with a transaction.
> So, some questions:
> * Am I correct in my belief that the _DBWithCursor helper object is giving
> me the semantics I want “for free”?
> * Is there a way I can use some attribute or method on _DBWithCursor,
> _DBWithCursor.db, etc. to abort its transaction?
> * If I need to use the low-level bsddb3.db API, can anyone suggest fixes
> for a horrible slowdown in put()s when I pass a transaction?
> I tried opening the DBEnv with flags:
> db.DB_INIT_TXN | db.DB_INIT_LOCK | db.DB_INIT_MPOOL | db.DB_TXN_NOSYNC
> and the DB_BTREE DB with flags:
> (When I found the DB_TXN_NOSYNC flag I really thought it was the answer,
> but it made no difference. But maybe I’m not using it right.)
> Thanks very much!
> pybsddb mailing list
> pybsddb at jcea.es
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pybsddb