public class RequestCacheController extends Object
A "request" is any relatively short-lived unit of work, which might be a user's HTTP request,
processing the incoming mail queue, reindexing a batch of issues, etc. The request-scoped
context is managed implicitly for HTTP requests and jobs the run within atlassian-scheduler.
It is also implied by the use of
and can alternatively be managed explicitly through this static utility.
|Constructor and Description|
|Modifier and Type||Method and Description|
Explicitly clears all request caches for the current thread.
Exit from a request caching context, destroying it if this context was not nested within another.
A convenient wrapper for running code within a context that participates in request caching.
Establish or re-enter a request caching context.
public static void startContext()
Calls to this method must be paired with the same number of calls to
If possible, this should be arranged by using a
try...finally that closes the context
finally block. Alternatively,
process(Runnable) will take care of
opening and closing the context for you.
public static void closeContext()
IllegalStateException- if no request cache context had been established
public static void clearAll()
You probably do not need this. It is intended for extreme cases, such as a data import performed from a user's thread, where it is known that the system's data has been drastically modified from within a single request's scope.
WARNING: This is only effective for the current thread. If you think you need to clear the request caches for all threads, then 1) You're wrong, and 2) That is impossible, anyway.
public static boolean isInContext()
trueif a request-scoped caching context has been established. When no request-scoped caching context is established, request caches revert to a read-through behaviour; that is, they will always pass every get request on to their cache loaders.
trueif a request-scoped caching context has been established;
public static void process(Runnable runnable)
If a request-scoped caching context does not currently exist, then one is established for the
runnable and destroyed afterwards. If a request-scoped caching context
has already been established, then there are no special side-effects; that is, the request
caches are already available and will not be flushed or destroyed by this method.
runnable- work to perform within a request-scoped context
Copyright © 2002-2017 Atlassian. All Rights Reserved.