ThreadLocal (and Singleton) in EJB Container

Question

I've written an authorization system which relies on objects representing the current user. To simplify programming and increase performance I want to hold those objects in a ThreadLocal after the user has logged in.

It looks like this:

public class UserCache {

    private static final ThreadLocal<User> cache = new ThreadLocal<User>();

    public User getCurrentUser() {
        return cache.get();
    }

    public void setCurrentUser(User user) {
        cache.set(user);
    }

}

I've read that static elements make clustering problematic. If I had an UserCache on each cluster node, they all had their own cache object not synchronized with the cache objects on other nodes. Right? UserCache is a classic candidate for a singleton, because the application needs only a single instance of it. But as far as I know @Singleton EJBs have the same behaviour in a cluster.

So what to do to make UserCache clusterable in an EJB 3.1 (Java EE 6) environment?

Solutions extracted from the answers:

• Using SessionScope from CDI (JSR 299) or
• Using JVM clustering with Terracotta

Answer 1

Since you're already on Java EE 6, wouldn't it even be a lot easier to use CDI (Contexts and Dependency Injection). This would allow to put the user info in the session scope , and inject it easily everywhere. CDI manages the rest for you.

Answer 2

that shouldn't cause you a problem, because threads don't span different nodes anyway - or am i missing the point of your question?

edit : you might want to look into something like terracotta - http://www.terracotta.org/ - for ways you can cluster existing objects

Answer 3

If you need to share objects between nodes, I would also suggest looking at the existing frameworks (like Terracotta).

Also, using ThreadLocal might possibly cause different problems:

http://forums.sun.com/thread.jspa?threadID=589744 http://www.devwebsphere.com/devwebsphere/2005/06/dont_use_thread.html http://www.theserverside.com/discussions/thread.tss?thread_id=21055

This may not be an issue here, though.