Cache handling in Koha

From Koha Wiki

Jump to: navigation, search
Home
Koha > Technical > Development

Contents

Technical discussion: cache handling in Koha

Decision

The discussion on koha-devel reached a consensus to use the ENV variable on koha-devel, feb,15th and the patches have been pushed on feb,21th

This discussion is now closed

Issue

There is more than one method to handle caching in Koha, and there are some patches that go in different directions:

Possible solutions : use of ENV vs. koha-conf.xml vs. DB/systempreferences to store memcached configuration.

Use of ENV

Pro

(copy/past of the mail Tomas Cohen sent to koha-devel)

I introduced the use of ENV (from Apache vhost definition) for storing memcached servers configuration data on Bug 6193. This was done for being able to cache the koha-conf.xml configuration variables (prior to that, memcached info was saved in koha-conf.xml itself and thus not-cacheable). When coding that I realized that memcached was being initialized everywhere we needed it. And namespaces where not always consistent (KOHA and koha alternatively, this might not be a problem if this happens to be case insensitive, anyway, it looked bad to me).

I then exported the object memcached and the ismemcached variable in C4::Context. This first patch (koha-conf.xml in memcache, and memcached object available for every other lib that includes C4::Context) has been pushed.

Then there's a second patch, that removes several memcached configuration validation and initialization code from the rest of the libs, and reuses that variables from C4::Context. I tested it to work flawlessly, but things around it halted when other proposals raised.

I like my approach. I like how the resulting code looked, I wont hide it. But I don't need it to be accepted at all, maybe the other proposals are far better. The only thing I missed on this cache thing was more feedback.

Back to the ENV use I think we must make a decision:

  • Do we want to cache koha-conf.xml ?
  • If the answer is no, then we can revert that patch. And we are done.
  • If the answer is yes, we can deal with it is storing the settings in the database, but this will make it difficult to memoize the function reading. Or leave it as it is now.

I don't agree it is a problem to move those settings to the vhost definition, it could be even moved into a separate file with an include sentence in the vhost definition for convenience (/etc/koha/memcached.conf and Include in vhost definition...)

Cons

This is the most technical place where we could put it. It requires a techie to switch this ON/OFF

Use of Koha-conf.xml

Pros

Cons

Use of systempreference

Pros

This is easily managed by a librarian itself

Cons

we can't cache anything that is loaded before systempreferences. So, we can't cache koha-conf.xml and systempreferences.

Votes

Use ENV

  • Tomas Cohen
  • Robin Sheat
  • Paul Poulain
  • Jared Camins-Esakov (what about adding a syspref to enable/disable caching globally, too?)

Use koha-conf.xml

Use systempreference

Personal tools