In order to interface with an existing multi-process system, I need to be able to respond to external events which signal the readiness of new values for certain data items.
I could write a caching Provider for each item, and inject the Provider's implementation into the event handler where it could be flush the cache on receipt of an event. However, it occurred me to model this process as a scope, much like @Singleton, but which occasionally gets flushed and re-populated. Has anyone encountered a need for a long-term scope which is global like Singleton, but not stack- or thread-based? Is there a better way to model externally-influenced Provider object cache flushes? Below are some details. Why it's not @Singleton or ThreadLocal CustomScope: I can't use a Singleton scope the lifetime of the provided value is not as long as the lifetime of the Injector. I can't use a ThreadLocal scope (as in the Guice documentation CustomScopes example), because the same objects are shared in all threads, and the flow of control in the consuming threads has no bearing on the lifetime of the objects. Concerns: This may sound like a recipe for a dirty read disaster, but I believe that I can use a new, asynchronous, long-term scope to implement the behavior I need to provide, as long as I accept one of the following: 1. All objects which inject from this scope must be in the scope, or 2. If there is more than one binding in the scope and an object outside the scope injects two Providers for two different objects within the scope, the two provided objects must not have inter-object consistency constraints, because two provider.get() calls may straddle a scope generation boundary. Fortunately, the application I'm converting to use Guice already satisfies #2 and I believe I can make use of #1 to make the relationships more explicit. Implementation: I've put together an implementation of a LongTermScope using the CustomScopes guide and Tim Peirel's org.directwebremoting.guice.AbstractContextScope for inspiration, in order to avoid the synchronized() in @Singleton. The scope has an three operations: enter, exit, and flip, an atomic exit-enter. It supports the CustomScope seed method as well, internally using a constant-valued Future subclass I felt compelled to call Destiny. Of course, this rolling-my-own-scope meets ConcurrentHashMap makes me nervous, so I'm interested in hearing of anybody has better ideas about how to model the event response, or has done something like this before. If there's need, I can provide the code for what I've done, but I don't have any faith in it yet. Thank you, Leigh. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
