[ZODB-Dev] nontransactional, oid, and thread safety. oh my!

Jim Fulton jim at zope.com
Thu Sep 30 06:10:28 EDT 2004


Tim Peters wrote:
> [Randy]

Thanks Tim, for the excelent reply....

...

>>If not, are they any good Storage implementations that don't do
>>transactions?
> 
> 
> No,

Right, but, there are storage implementations that don't require packing.

In particular, the Berkeley DB storage doesn't need to be packed
at all of you avoid cyclic references among persistent objects and
doesn't need to be packed to get rid of old revisions. (Actually,
it packs automatically.)  With this storage, you get the benefits of
transactions without getting large database growth.  You *do* then
need to follow best Berkeley DB practices, like log-file management.

...

>>Are those oid's publicly available?
> 
> 
> It's hard to say what the public API is <wink/sigh>.  A persistent object
> obj's oid is inspectable via obj._p_oid, and lots of people access it.
> Whether they should is open to debate.

Technically, they are publically available, but it's often a bad idea
to use them at the application level.  Doing so is regarded as an
:advanced" application.

>>I'm using an incrementing counter stored in the database, for my id's.
>>However, I'd much rather use the ones in the database.

It is better to use your own application ids.

...

> ZODB was not intended for high
> write-conflict scenarios, though.

It should be noted that high-write conflicts, otherwise known as
"hot spots" are to be avoided in any application.  No matter what database
you use, write conficts should be avoided to the degree possible.


>>I've also read about using a connection object for each thread.

This is the recommended approach.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


More information about the ZODB-Dev mailing list