[ZODB-Dev] shared cache when no write?

[Jim Fulton]

On Thu, Dec 13, 2012 at 4:18 PM, Dylan Jay <djay at pretaweb.com> wrote:
...
> I'd never considered that the cache was attached to the db connection rather
> than the thread. I just reread
> http://docs.zope.org/zope2/zope2book/MaintainingZope.html and it says
> exactly that.
> So what your saying is I'd tune db connections down to memory size on an
> instance dedicated to io bound and then increase the threads. Whenever a
> thread requests a db connection and there isn't one available it will block.
> So I just optimize my app the release the db connection when not needed.
> In fact I could tune all my copes this way since a zone with 10 threads and
> 2 connections is going to end up queuing requests the same as 2 threads and
> 10 connections?

Something like that. It's a little more complicated than that because
Zope 2 is managing connections for you, it would be easy to run afoul
of that.  This is a case where something that usually makes your life
easier, makes it harder. :)

What I'd do is use a separate database other than the one Zope 2 is
using.  Then you can manage connections yourself without conflicting
with the publisher is doing.  Then, when you want to use the database,
you just open the database, being careful to close it when you're
going to block.  The downside being that you'll have separate
transactions.

> This should be easier to achieve and changes the application less than the
> erp5 background task solution mentioned.

It would probably be a good idea to lean more bout how erp does this.
The erp approach sounds like a variation on what I suggested.

> I can see from the previous post, as there is no checkout semantics
> in zodb,

I don't know what "checkout semantics" means.

> you are free to write anytime so there is no sane way to block at the point
> someone wants to write to an object, so it wouldn't work.

ZODB provides a very simple concurrency model by giving each
connection (and in common practice, each thread) it's own view of the
database. If you break that, then you're injecting concurrency issues
into the app or in some pretty magical layer.

> You perhaps could have a single read only db connection which is
> shared?

But even if the database data was only read, objects have other state
that may be mutated.  You'd have to inspect every class to make sure
it's thread safe. That's too scary for me.

Jim

--
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://zo.pe/Kqm