CALL FOR:
new project: query cache release framework
Called by: Ernst Bunders
Total tally on this call (excluding the caller's vote) : +8
START OF VOTING: 2005-08-09 15:00
END OF CALL: 2005-08-15 12:00
YEA (8) : Michiel Meeuwissen, Ernst Bunders*, Pierre van Rooden, Rico
Jansen, Rob Vermeulen, Kees Jongenburger, Eduard Witteveen, Andre van
Toly, Marcel Maatkamp
ABSTAIN (0) :
NAY (0) :
VETO (0) :
No votes, assumed abstained (8): Jaco de Groot, Johannes Verelst, Daniel
Ockeloen, Nico Klasens, Rob van Maris, Gerard van Enk, Mark Huijser,
Simon Groenewolt
*) This vote needs a total tally of +3 votes in addition to any in favor
vote of the vote's caller.
Result:
The vote succeeded, a project space will be created.
Ernst Bunders is project leader.
Ernst Bunders wrote:
Hello
As has become clear (i hope) i spend some time deloping a small
framework for query cache release strategies. This aimes at solving twoo
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
becouse you can easily scale on that tier through clustering, if you can
not scale on the database tier)
I hope some people will want to join this (little) project for there are
some things yet to be done, and it needs to be tested well becouse it
touches some vital parts of mmbase.
Some people suggested I should give a presentation about this first.
That's ok with me (and i promis i will try to make it better that the
last one :) )
for more details i recommend reading my preveous mail of 2005-08-02
included is a project proposal (in docbook)
START OF VOTING: 2005-08-09 15:00
END OF CALL: 2005-08-16 12:00
[_] +1 (YEA)
[_] +0 (ABSTAIN )
[_] -1 (NAY), because :
[_] VETO, because:
regards,
Ernst
--
Pierre van Rooden
Mediapark, C 107 tel. +31 (0)35 6772815
"Anything worth doing is worth overdoing."
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
