[SR-Dev] Usrloc, Databases, and Caching

[Henning Westerholt]

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?

Hi Martin,

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 
patches.

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.

Cheers,

Henning