CoreCache

Perform a non-transactional insertion into the cache, returning a FastlyBody instance for providing the cached object itself. For the insertion to complete successfully, the object must be written into the returned FastlyBody instance, and then FastlyBody.prototype.close must be called. If FastlyBody.prototype.close does not get called, the insertion is considered incomplete, and any concurrent lookups that may be reading from the object as it is streamed into the cache may encounter a streaming error.

Note: Like CoreCache.lookup(), CoreCache.insert() may race with concurrent lookups or insertions, and will unconditionally overwrite existing cached items rather than allowing for revalidation of an existing object. The transactional equivalent of this function is TransactionCacheEntry.insert(), which may only be called following a CoreCache.transactionLookup() call and the returned CacheEntry when has a state where CacheState.mustInsertOrUpdate() returns true.

Perform a non-transactional lookup into the cache, returning a CacheEntry if a usable cached item was found. A cached item is usable if its age is less than the sum of its TTL and its stale-while-revalidate period. Items beyond that age are unusably stale.

Note: A non-transactional lookup will not attempt to coordinate with any concurrent cache lookups. If two instances of the service perform a lookup at the same time for the same cache key, and the item is not yet cached, they will both return null. Without further coordination, they may both end up performing the work needed to insert() the item (which usually involves origin requests and/or computation) and racing with each other to insert. To resolve such races between concurrent lookups, use CoreCache.transactionLookup() instead.

Perform a transactional lookup into the cache, returning a TransactionCacheEntry instance.

Transactions coordinate between concurrent actions on the same cache key, incorporating concepts of request collapsing and revalidation, though at a lower level that does not automatically interpret HTTP semantics.

Request Collapsing: If there are multiple concurrent calls to CoreCache.transactionLookup() for the same item and that item is not present, just one of the callers will be instructed to insert the item into the cache as part of the transaction. The other callers will block until the metadata for the item has been inserted, and can then begin streaming its contents out of the cache at the same time that the inserting caller streams them into the cache.

Revalidation: Similarly, if an item is usable but stale, and multiple callers attempt a CoreCache.transactionLookup() concurrently, they will all be given access to the stale item, but only one will be designated to perform an asynchronous update (or insertion) to freshen the item in the cache.

Issue a transactional lookup into the cache without blocking, returning a PendingTransaction.

This behaves like CoreCache.transactionLookup() (the same request collapsing and revalidation semantics apply), except that the lookup itself does not block: instead of returning a TransactionCacheEntry directly, it returns a PendingTransaction which can be polled via PendingTransaction.prototype.pending, or resolved via PendingTransaction.prototype.wait, optionally bounded by a timeout.