zodb & multiple processes

Paul Everitt paul at digicool.com
Sat Jan 13 10:37:22 EST 2001


Just to add a point on Kapil's info.  ZEO is certainly more heavyweight on
reads and writes when it doesn't have the data locally.  However, ZEO has
two levels of cache on the individual processes (in-memory and on disk), and
transactions committed in another process send cache invalidation messages
to other clients.

For some types of applications (such as web apps), this approach works.
There are many times more reads than writes for most web apps, and usually a
minority of the objects are used a majority of the time.  For other types of
apps this approach can incur the network and pickling overhead.

With the move to BSDDB3 as the preferred storage for future ZODB work, this
might open up some opportunities for multiprocess access.

--Paul

On 1/10/01 10:00 PM, in article
Yk976.1119$mX.27921 at newsread2.prod.itd.earthlink.net, "Kapil Thangavelu"
<kthangavelu at earthlink.net> wrote:

> yes the zodb is thread safe (zope is multithreaded). it actually makes
> programming
> multithreaded programs a bit easier as objects which inherit from the
> persistent classes
> become thread safe (although it assumes a bit optimism regarding the rate of
> object changes,
> the optimism won't corrupt your data but its something to be aware of).
> 
> as long as your're objects are not changing frequently its a pretty good way
> to avoid lots of
> concurrency control around your objects.
> 
> currently the zodb assumes a process lock on a particular zodb storage. if
> you want to run it with
> multiple processes you can use ZEO, which is a bit heavyweight if you want
> your app to run on
> one machine as it communicates over tcp/ip.
> 
> for more info check out jim fulton's IPC 8 paper on zope.org and amk's
> starship homepage.
> 
> kapil
> 
> 
> Erno Kuusela <erno-news at erno.iki.fi> wrote in message
> news:kuhf36hotz.fsf at lasipalatsi.fi...
>> hello,
>> 
>> from the looks of things, zodb is thread-safe in that you can use
>> connections to the same storage from many threads at once and
>> have it not break.
>> 
>> how about multiple processes? will it just work, just not work,
>> or require special incantations?
>> 
>>   -- erno
> 
> 




More information about the Python-list mailing list