MMBase
Homepage / Roadmap - bugs / Projects

Persons

Ernst Bunders (project leader)

Pierre van Rooden

André van Toly

Nico Klasens

Michiel Meeuwissen

Attachments

word doc project introduction
this document describes the purpose of this project in some more detail than the project proposel documetn

file Project proposal (docbook)
Project proposal Query Cache Framework

word doc poject meeting digest
tuesday 25 aug. we had a first project meeting. Here is a overview.

file event model docuemtation
This is a document to explain the new event system, and show how to create your own event types

Query Cache Release Framework

This aimes at solving two problems.

1. Currently caches are invalidated way to quickly. there is no proper
evaluation of changes (events) prior to flushing queries and their
result sets from the cache.

2. Extensiblility: This framework will provide a simple way to optimize
cache release behavour for specific applications.
example:
Think of a forum with forum and forumpost nodes. Presently, when you
commit a forumpost, all queries containing a forumpost are being flused.
With the framework in place you can easily write some code to check if
the evaluated queries in the cache query the same forum that this
forumpost was posted into, and if not, you don't have to flush the
query. This can be done either by examening the cached query object or
examining the stored result set (the latter being obveously more
expensive).

The structure will be plugin like. you can create a release strategy
class by extending an abstract base strategy class, and simply load it
(during runtime or by configuring the caches.xml file). the plugins form
a hyrarchie that is being traversed for each query in a cache until some
rule decides the query should not be flushed.

Extra benefits are: performance measuring like avarage processing time
of a strategy class and effectiveness, so you know at wat processing
cost at the middel tier you are sparing your database tier. This allows
for interesting optimization strategies (you could choose to take a lot
of load to the middle tier by elaborate and expesive optimizations
because you can easily scale on that tier through clustering, if you can
not scale on the database tier)