> -----Oorspronkelijk bericht----- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Namens Michiel Meeuwissen > Verzonden: maandag 15 augustus 2005 14:31 > Aan: Discussion list for developers > Onderwerp: Re: [Developers] VOTE: new project: query cache > release framework > > > 2005/8/9, Ernst Bunders <[EMAIL PROTECTED]>: > > 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 > > > > [X] +1 (YEA) > > > I have not yet grasped the full extension of the proposal, so > my vote is mostly based on the notion that it would be good > to look at this stuff more closely. >
well, i guess that's why we make it a project. It is not completely finished, and needs some work and cooperation. Great you join. Ernst > Smarter cache-invalidation is welcome. > > I'm prepared to take part in the project, also because I'm > partially responsible for the current implementation. > (Actually, I think I more or less rewrote it, withough > changing funcitonality). > > Michiel > > > > > -- > mihxil' http://mihxil.komputilo.org/ > nl_NL eo_XX en_US _______________________________________________ > Developers mailing list > [email protected] > http://lists.mmbase.org/mailman/listinfo/developers > _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
