On Tuesday 09 December 2008, Martin Hoffmann wrote: 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. 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

Martin Hoffmann wrote: we have thought of it a couple of times, but it always remind sort of nice-to-have, maybe because in many cases doing just a local DB replica does a comparable job for the read-only tables. -jiri