[Dbix-class] Soliciting Design Input for an Object Caching Module

Brandon Black blblack at gmail.com
Wed May 16 02:21:27 GMT 2007


On 5/15/07, Johan Lindström <johanl at darserman.com> wrote:
> At 00:15 2007-05-16, Brandon Black wrote:
> >While I think caching at the DBIx::Class level will be useful for some
> >people, I would think that a lot of users would leave it turned off
> >for consistency reasons.  Even if you're invalidating the cache
> >locally on update/delete, that's local to one process.
>
> <delurking>
>
> Isn't that really up to the design of the cache being used?
>

Yes.

> If you use two in-memory caches (i.e. in process) for two processes, they
> will become out-of-sync. So that's the wrong solution. They should use an
> on-disk cache that is common to the processes.
>

s/on-disk/in-memory/;

> Same for processes across machines, they shouldn't have two machine local
> caches, they should use a centralized cache, or memcached, or some other
> setup that is distributed across the machines.
>

Yes, that's what I said :)

> But again, isn't that up to the cache itself (and the
> configuration/deployment of it) to deal with? Not DBIC.
>

I would assume that different caches have different interfaces and
behaviors, and we need to either write to a really useful one
(memcached gets my vote), or we need to first abstract all of the
useful caching backends into something generic we can use (kinda like
how Storage abstracts DBI).

-- Brandon


More information about the Dbix-class mailing list