[SR-Dev] Usrloc, Databases, and Caching
henning.westerholt at 1und1.de
Wed Dec 10 11:42:49 CET 2008
On Tuesday 09 December 2008, Martin Hoffmann wrote:
> [DB API..]
> Since we were talking about it internally, I was thinking a bit about
> the future of usrloc. It has this thing where it caches entries in
> memory. Now, technically usrloc is just a database (or maybe a database
> on top of a database). Wouldn't it make sense to get rid of it and
> instead implement a database module that caches and then simplify the
> registrar module to use database queries directly?
indeed, usrloc is more or less just a abstraction layer on top of the DB. Some
people (e.g. we) even don't use the provided caching infrastructure because
they want to keep it simple, or extend the standard usrloc with custom
This is one of the reasons i don't really like the idea of moving the cache to
the DB layer, because this would probably increase the overhead of all DB
operations, and making the whole system more complex.
> This has the benefit that other modules can suddenly use caching, too,
> if they want. In SER, the domain module for instance already does some
> caching, so there is some code replication.
> I believe the database API to be simple enough to provide caching
> especially since the new model with pre-registered queries allows the
> cache to be set up with those queries in mind.
Another issue is, that in order to really benefit from the cache, the cache
needs a certain structure or layout, some locking facilities etc.. that must
be adapted to the needs of the application. So i doubt that this general DB
cache can be used efficiently from usrloc, and some other modules, e.g.
carrierroute or the domain module.
If this cache just acts as a generic query result cache, this is already
included in common database servers, like mysql. If their standard cache
behaviour is not sufficient, i think this can be increased in the
configuration, given that enough memory is available. If some want to avoid
the remote server communication overhead, just use a local replication slave.
So i don't see at the moment a compelling need to include functionality like
this in our codebase.
If there is a need for a generic (object) caching facility, i think we should
rather try to use an existing implementation, perhaps something like
memcached, instead of implementing a complete new one.
More information about the sr-dev