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. 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
