Prado does not allow custom SqlMap data caching strategy/method & has inefficient Basic cache

Prado currently does not allow an application developer to define some own 
caching strategy, additional to the built-in ones (Basic, FIFO, LRU). 

This is very limiting, especially, that the built-in Basic cache method 
(implemented in TSqlMapApplicationCache) gets very slow and ineffective in 
high-concurrency situations. This is because it maintains a separate list of 
the entries being cached - which 
1. might grow very large, and thus slow to read and write
2. needs to be retrieved and deserialized additionally to retrieving the result 
set itself, and also if the item being request is not actually cached anymore. 
the same holds true for situations where result sets are being added to or 
deleted from the cache, in which case the list in question also needs to be 
serialized and written, additional to the result sets added/deleted.
3. might also be written to even then when the cache is being only read by the 
sql mapper (this poses an extra burden on concurrency, because write operations 
are excluding all other parallel reads or writes to the cache during their 
execution)
4. is highly prone to contain and return incosistent data sets during flushes 
of the cache model (because flushes take tons of separate cache delete 
operations in the current implementation, which might take "ages" to complete, 
during which other, parallel queries will return already outdated results, 
depending on how far the flush has already progressed in the cache set)

To overcome the above problems I've extended the original TSqlMapCacheModel 
class so it now allows registration and use of custom caching 
methods/strategies in SqlMap definitions. I've also created an alternative 
implementation to the original Basic cache method, which works practically the 
same way (ie. it stores the cached result sets in the application cache), but 
works a lot faster and returns consistent results even in high-concurrency 
situations, by avoiding maintenance of a separate result set list and employing 
an atomic flushing operation. It achieves that by practically pushing the 
burden of the disposal of invalidated result sets onto the used cache's garbage 
collection routine - which, however, is practically always far more effective 
at doing that, than the PHP code.

The new class can be registered either as a separate caching method with for ex.

 TSqlMapCacheModel::registerCacheType('Fast', 'TFastSqlMapApplicationCache');

or alternatively can be used to override the default Basic caching strategy with

  TSqlMapCacheModel::registerCacheType(TSqlMapCacheTypes::Basic, 'TFastSqlMapApplicationCache');

Original issue reported on code.google.com by google...@pcforum.hu on 28 May 2012 at 2:33

Attachments:

power-media / prado3

Prado does not allow custom SqlMap data caching strategy/method & has inefficient Basic cache #407