Non-thread-based request scoping

[Luke Sandberg]

I think there might be some performance concerns, since the cost of
creating a child injector scales wither number of bindings in the child
injector. Whereas using request scope you just pay the overhead (of the
threadlocal interactions) for the bindings that you actually use in a
request. For large applications there might be a large difference between
these two numbers.

So would you say I shouldn't worry about the cost of creating child
injectors on every request? I sort of like this approach. Having to
transfer state between thread locals seems error-prone.
Correct. Child injectors were designed with this very use case in mind. Of
course, you'll want to avoid slow operations in your request-scoped
modules. Child injectors are less error prone than Scopes because they make
it impossible for an object in a larger scope to directly reference an
object in a smaller scope (for example, a global singleton can't be
injected with a request-scoped object).
Bob
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/CAGmsiP4Stf2KZtE%3De85GCzUVNuNxj8DSg-2y5Kg%2BTHfKmJaYzQ%40mail.gmail.com
<https://groups.google.com/d/msgid/google-guice/CAGmsiP4Stf2KZtE%3De85GCzUVNuNxj8DSg-2y5Kg%2BTHfKmJaYzQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Tim Boudreau]

I did this for a Guice-based framework I built of top of Netty
- https://github.com/timboudreau/acteur - as follows:

First, some base classes for custom scopes:
https://github.com/timboudreau/scopes

And basically, since my code controls thread dispatch, you simply wrap any
Runnable/Callable that is going to expect to be able to inject
request-specific objects in another Runnable/Callable that first re-enters
the scope with the same objects it had before. You can make this even more
transparent by wrapping an ExecutorService with one which:

- Whenever new work is scheduled *from* a thread that is already in-scope,
it is wrapped in such a Runnable/Callable

Now, whether Play has the entry points you'd need to control dispatch in
this way, I don't know. But basically, when a request comes in, you fill
up a bag with the objects you want to be injectable, and "enter" the scope
with them. When the request processing code schedules something, you give
it a copy of that bag, and before the code to be scheduled is invoked, you
re-enter the scope with its former contents.

pseudocode example:

ReentrantScope scope = ...

public void schedule(Runnable r) { // assume this is a thread pool,
whatever thread mgmt mechanism you or Play uses
super.schedule (new ScopedRunnable(r));
}
...

class ScopedRunnable implements Runnable {
final Object[] contents;
final Runnable delegate;
ScopedRunnable(Runnable delegate) {
this.contents = scope.contents();
this delegate = delegate;
}

public void run() {
scope.enter(contents);
try {
delegate.run();
} finally {
scope.exit();
}
}

(that's fairly rough code, but hopefully you get the idea - there are some
convenience methods in the scopes library to make this sort of thing
simple).

-Tim