Question

It seems that all Guice’s out-of-the-box Scope implementations are inherently Thread-based (or ignore Threads entirely):

Scopes.SINGLETON and Scopes.NO_SCOPE ignore Threads and are the edge cases: global scope and no scope.

ServletScopes.REQUEST and ServletScopes.SESSION ultimately depend on retrieving scoped objects from a ThreadLocal<Context>. The retrieved Context holds a reference to the HttpServletRequest that holds a reference to the scoped objects stored as named attributes (where name is derived from com.google.inject.Key).

Class SimpleScope from the custom scope Guice wiki also provides a per-Thread implementation using a ThreadLocal<Map<Key<?>, Object>> member variable.

With that preamble, my question is this: how does one go about creating a non-Thread-based Scope? It seems that something that I can use to look up a Map<Key<?>, Object> is missing, as the only things passed in to Scope.scope() are a Key<T> and a Provider<T>.

Thanks in advance for your time.

Answer 1

It’s a bit unclear what you want – you don’t want scopes that are based on threads, and you don’t want scopes that ignore threads.

But yes, scopes are intended to manage the lifecycle of an object and say when an instance should be reused. So really you’re asking “what are the other possibilities for re-using an instance beyond ‘always use the same instance’, ‘never use the same instance’, and ‘use an instance depending on the execution environment of the current thread’?”

Here’s what comes to mind:

• Use the same instance for a fixed amount of time. The example here would be of a configuration file that’s reloaded and reparsed every ten minutes.
• Perform some network call to query whether a given object should be re-used (maybe it’s a fast call to determine whether we need to reconstruct the object, but the call for reconstructing the object is slow)
• Re-use the same object until some outside call comes in telling us to reload
• Re-use the same object per thread, but not with a scope that’s explicitly entered and left like the servlet scopes. (So one instance per thread)
• A “this thread and child threads” scope that is based on an InheritableThreadLocal, not a plain ThreadLocal.
• Related to that, a Scope and a threadpool-based ExecutorService that work togehter so that instances are shared between a thread and jobs it submits for background execution.
• Pull instances out of a pool; this is tricky, since we’d need a good way to return objects to the pool when finished. (Maybe you could combine this idea with something like the request scope, so that objects can be returned to the pool when the request ends)
• A scope that composes two or more other scopes, so for example we could get a configuration object that is re-read every 10 minutes except that the same instance is used through the lifetime of a given request.