Blog About Contact

Clustering Guice Java Web Applications

Published Tue, 31 Aug 2010

Considering the origin of Guice (it's use in Google Adwords, one of the largest apps on the Internet), it's fair to say it should support clustering / session replication.

There's not much in the way of documentation around that aspect of it.

As it turns out, there's a good reason for that - clustering and session replication with Guice are mind-numbingly simple. In fact, if you're doing session replication / fail-over, you probably already have it working.

This is because, @SessionScoped objects in Guice are stored in HttpSession, and with consistent internal keys.

That might be obvious to some people, but it wasn't to me. I thought that Guice used... well... MAGIC or something to keep track of objects in session scope.

Actually, delving into the Guice internals, here's the "magical" code -

  public static final Scope SESSION = new Scope() {
    public  Provider scope(Key key, final Provider creator) {
      final String name = key.toString();
      return new Provider() {
        public T get() {
          HttpSession session = GuiceFilter.getRequest().getSession();
          synchronized (session) {
            Object obj = session.getAttribute(name);
            if (NullObject.INSTANCE == obj) {
              return null;
            T t = (T) obj;
            if (t == null) {
              t = creator.get();
              session.setAttribute(name, (t != null) ? t : NullObject.INSTANCE);
            return t;
        public String toString() {
          return String.format("%s[%s]", creator, SESSION);

So the GuiceFilter servlet filter is actually what provides the magic for this functionality. The actual objects are stored in the HttpSession as attributes.

So in order to support session replication you just need to make sure that your session scoped objects are Serializable, and everything is good. Normal HttpSession replication across your cluster will mean everything works as expected.

Of course, what if you have non-serializable dependencies?

Well they can be @Inject'ed into a static member variable to get around that, though I'd suggest a better solution would be to refactor the code such that the data (Serializable) component is kept in session scope, but the functional (non-serializable) part is split out into a @Singleton service class.

About the Author

Richard Nichols is an Australian software engineer with a passion for making things.

Follow him on twitter or subscribe by RSS or email.

You might also enjoy reading -

Discuss / Comment

No one has commented yet.

Add a comment

  • {{e.error}}

Thanks for your comment!/

Valid email address required.
Posting message, please wait...