On 3/18/2015 1:46 PM, Jacopo Cappellato wrote:
On Mar 18, 2015, at 2:35 PM, Adrian Crum <adrian.c...@sandglass-software.com>
wrote:
I would be interested in seeing a use case for that.
This is just an example I could think of (there may be other better examples
but I am in a rush and I can't concentrate):
Client code A selects a bunch of records from TableFoo in order to update them;
cache is disabled to prevent the creation of cache entries that would be
expired after a few milliseconds.
Delegator makes a database call to get the bunch of records.
Client code B selects a bunch of records from TableFoo in order to format a
list in a web page; cache is enabled in order to hit the cache after the first
visit to the page.
Delegator makes a database call to get the bunch of records.
If client code A used the cache, then client code B would not have to
make a database call (or the reverse).
The problem with your use case is, a developer is trying to determine
the best caching strategy, and that is not something you can decide at
design time. Instead, that is a decision that needs to be made during
staging - where you can measure the real-world effects of concurrent
processes.
Adrian Crum
Sandglass Software
www.sandglass-software.com
