• New Feature
  • Status: Open
  • 2 Major
  • Resolution:
  • prodmgmt
  • Reporter: steve
  • July 12, 2011
  • 0
  • Watchers: 0
  • May 06, 2013

Description

I was talking to one of our old users about what we had built and he raised the question of how we could leverage the cost of recreation into the stickiness of entries.

I was thinking that this would be pretty easy in the case of SelfPopulatingCache since we already control the life cycle. Plus we could add it to our explicity locking API (and or a new API) that times the app operation.

Comments

gluck 2011-07-14

This is an interesting area.

It is often the case that there are radically different costs to recreate entries. For example take the Hibernate query cache. Some queries will execute in ms and some could take minutes, Yet they are all treated the same.

And in our new AMM we use bytes as a proxy for expense in selecting which cache to evict from.

Time taken to recreate is a pretty could proxy for expense. And it can apply to many things. Network latency is largely constant. So time varies depending on processing. This applies to web services, data base calls etc etc.

We could:

1) Add a long field called cost to Element. 2) Automatically record the time in ms in that field in SelfPopulatingCache, CacheLoader, Web Cache and Explicit Locking API. 3) Modify the eviction algorithm to take into account LRU and also cost, similar to what was done for AMM. We could modify the current algorithm to just use it where the values are recorded. 4) If the values are not recorded leave the field as null to save storage space. 5) Modify AMM to use this improved data on cost.