item expiration

[Nelz]

What you're talking about here sounds a heck of a lot like one of the
use cases I've heard about GigaSpaces/OpenSpaces...  (Where everything
gets slurped into JVM space on startup, and the DB is only used as a
starting point and backup location...) You might wanna look into that.

- Nelz

On Wed, Jun 11, 2008 at 9:59 PM, Grant Maxwell
<grant.maxwell at maxan.com.au> wrote:
>
> Dustin:         Is there not a step like, ``if it's not cached, we need to
> look it up?''  If not, then it seems like you want something more along the
> lines of dynamo/chubby/zookeeper for these items.
>
> Dustin In this particular case to do that would completely negate the
> benefit of the cache because better than 99% would fail in the cache lookup
> AND the database lookup. In effect we would be using the cache as a virtual
> table and only refer to the database on startup. There is method in our
> "madness" uhahaha. The number of "rogue" actions requested that would be
> blocked may only represent 10% of our total action requests, but would
> reduce server load significantly.
>
> I take the point of some folk who have suggested running a 2nd instance of
> memcached and I am thinking about that. The single downside is calculation
> of the memory requirement and getting it right so that we don't lose entries
> and don't waste memory.
>
> I've not heard of dynamo etc and will look into them.
>
>
> regards
> Grant
>
>
>
>
> On 12/06/2008, at 2:37 PM, Dustin Sallings wrote:
>
>>
>> On Jun 11, 2008, at 18:02, Grant Maxwell wrote:
>>
>>>        If the class is cached and the record exists then we allow the
>>> action to proceed.
>>>        If the class is not cached then we just allow the action to
>>> proceed
>>>        if the class is cached but the record does not exist then the
>>> action is denied.
>>
>>        Is there not a step like, ``if it's not cached, we need to look it
>> up?''  If not, then it seems like you want something more along the lines of
>> dynamo/chubby/zookeeper for these items.
>>
>>        The proposals that make sense to me around LRU policies are more
>> for QoS kinds of things.  That is, you can rate something between ``this is
>> a little cheaper than recomputing it, but whatever'' to ``for the love of
>> [deity] do not uncache this before the expiration date.''  Even in the
>> latter case, you must accept that the value *may* not be where you think it
>> is and will need to be recomputed.
>>
>>        The only time I really see making a business decision based on what
>> value is in the cache is if you're under a heavy load scenario and are
>> really trying to walk on eggshells around your centralized resource.  e.g.
>> you might give an HTTP 503 kind of response, but definitely nothing in the
>> 400s.
>>
>> --
>> Dustin Sallings
>>
>>
>>
>
>