Hi Mike,

I haven't heard from you in a long time and I'm glad to know
you are still making the world better.

Each client must keep track of a set of objects that are all current
as of the last commit or abort.  I know this is true of Durus and
I think it is true of ZODB as well.  Each change made by a client
must be recorded by that client and by no others.  This makes it
rather awkward to truly share objects between clients in
different threads.  I could be wrong, but I think Durus and ZODB
are the similar in this respect.    If you really want a single cache
and correct transactional processing, maybe you should run
SCGI with only one scgi client.  If you can afford the memory,
as I suspect you can, then maybe multiple Durus clients are okay.

Good luck with your updates, whatever you decide to do.

- David

On Jul 23, 2008, at 6:35 PM, Mike Orr wrote:

> I'm porting my Quixote/Durus application to Pylons, which has a
> multithreaded server.  It's kind of a pain to make a connection
> threadlocal and initialize it in each thread, and I'd also like a
> shared object cache rather than one in each thread. The database is
> prebuilt and readonly, so there's no modifications going on.  Right
> now with three SCGI subprocesses, each process is 110 MB containing
> mostly the memory cache.  We do a lot of complex searches so search
> speed is more important than memory use, still it would be nice to
> have one 80MB cache rather than multiple.  Is this possible in Durus?
>
> An alternative would be going to ZODB, which is thread safe.  However,
> Durus has been working well for us and I have only a few months to
> upgrade the application, so I'd rather not switch to a new library.
>
> Another issue is this will have to run both as a web app and as a
> standalone (a local web app under wxPython).  So far this is working
> with Quixote and Durus.  We'll have to see how Pylons does with it.
>
> --
> Mike Orr 
> _______________________________________________
> Durus-users mailing list
> Durus-users@mems-exchange.org
> http://mail.mems-exchange.org/mailman/listinfo/durus-users