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