polling-cache-0.1.1.0: Cache infrequently updated data for simpler distributed systems.
Safe HaskellSafe-Inferred
LanguageHaskell2010

Data.Cache.Internal

Description

Caching implementation internals.

This module is not part of the Data.Cache public API and should not be directly relied upon by users. Anything meant for external use defined here will be re-exported by a public module.

Synopsis

Documentation

class (MonadCatch m, MonadIO m) => MonadCache m where Source #

The top-level Monad in which caching operations are performed.

This exists primarily for testing purposes. Production uses should drop in IO and forget that this exists.

Methods

currentTime :: m UTCTime Source #

The current system time.

randomize :: (Int, Int) -> m Int Source #

Generate a random number between two bounds (inclusive).

delay :: Int -> m () Source #

Delay execution of the current thread for a number of microseconds.

newThread :: m () -> m ThreadId Source #

Spawn a new thread of execution to run an action.

repeatedly :: m () -> m () Source #

Run an action forever.

killCache :: ThreadId -> m () Source #

Stop a thread of execution. The thread can be assumed to have been started using newThread.

Instances

Instances details
MonadCache IO Source # 
Instance details

Defined in Data.Cache.Internal

data DelayMode a Source #

The supported delay modes for a PollingCache instance.

The delay associated with a cache instance define the amount of time that will pass between cache refreshes.

Constructors

DelayForMicroseconds Int

Delay for static number of microseconds between each refresh.

DelayDynamically (Either SomeException a -> Int)

Delay for a dynamic number of microseconds between each refresh.

This is useful if different delays should be used for successes or failures, or if the result being retrieved contains information that could affect the delay period.

DelayDynamicallyWithBounds (Int, Int) (Either SomeException a -> Int)

Delay for a dynamic number of microseconds between each refresh within a set of bounds.

This is similarly useful to DelayDynamically, but when a known lower and upper bound should be applied to the delay period. Regardless of the dynamic delay generated by the user-supplied function, the delay period will never be below the lower bound or above the upper bound.

data FailureMode Source #

The supported failure handling modes for a PollingCache instance.

In the context of the cache action, "failure" means an Exception thrown from the user-supplied action that generates values to populate the cache.

Because these operations are performed in a background thread, the user must decide how failures are to be handled upon cache creation.

Constructors

Ignore

Failures should be ignored entirely; the most relaxed failure handling strategy.

This means that LoadFailed will never be populated as a cache result.

EvictImmediately

If a failure occurs, any previously cached value is immediately evicted from the cache; the strictest failure handling strategy.

EvictAfterTime NominalDiffTime

Failures will be ignored unless they persist beyond the supplied time span.

This is a middle-ground failure handling strategy that probably makes sense to use in most scenarios. The nature of asynchronous polling implies that somewhat stale values are not an issue to the consumer; therefore, allowing some level of transient failure can often improve reliability without sacrificing correctness.

Instances

Instances details
Eq FailureMode Source # 
Instance details

Defined in Data.Cache.Internal

Show FailureMode Source # 
Instance details

Defined in Data.Cache.Internal

data CacheOptions a Source #

Options that dictate the behavior of a PollingCache instance.

Constructors

CacheOptions 

Fields