synchronized access to HttpSession attribute vs static ConcurrentMap with HttpSessionListener

Question

As a part of library implementing websocket Guice scopes I need to maintain an object related to each HttpSession called sessionContextAttributes. Currently sessionContextAttributes is stored as an attribute of a session, which means the access and initialization needs to be synchronized:

ConcurrentMap<Key<?>, Object> getHttpSessionContextAttributes() {
    HttpSession session = getHttpSession();
    try {
        synchronized (session) {
            @SuppressWarnings("unchecked")
            var sessionContextAttributes = (ConcurrentMap<Key<?>, Object>)
                session.getAttribute(SESSION_CONTEXT_ATTRIBUTE_NAME);
            if (sessionContextAttributes == null) {
                sessionContextAttributes = new ConcurrentHashMap<>();
                session.setAttribute(SESSION_CONTEXT_ATTRIBUTE_NAME, sessionContextAttributes);
            }
            return sessionContextAttributes;
        }
    } catch (NullPointerException e) { /* ... */ }
}

static final String SESSION_CONTEXT_ATTRIBUTE_NAME =
        ContainerCallContext.class.getPackageName() + ".contextAttributes";

Now I'm considering to maintain a static ConcurrentMap from HttpSession to sessionContextAttributes like this:

static final ConcurrentMap<HttpSession, ConcurrentMap<Key<?>, Object>> sessionCtxs =
        new ConcurrentHashMap<>();

ConcurrentMap<Key<?>, Object> getHttpSessionContextAttributes() {
    try {
        return sessionCtxs.computeIfAbsent(
                getHttpSession(), (ignored) -> new ConcurrentHashMap<>());
    } catch (NullPointerException e) { /* ... */ }
}

This simplifies getHttpSessionContextAttributes() method and is probably slightly faster, BUT introduces static data AND requires manual removal to prevent leaking of sessionContextAttributes:

static class SessionContextJanitor implements HttpSessionListener {

    @Override
    public void sessionDestroyed(HttpSessionEvent event) {
        sessionCtxs.remove(event.getSession());  // this avoids resource leaks
    }
}

I cannot confidently tell which approach is better: both have pros&cons. Hence I'm posting it here for review: maybe someone knows some reasons that make 1 of these approaches significantly better than the other.

Answer 1

After some more research and thinking, it turned out that both of the above approaches are wrong ;-]
The reason for both cases is that user Filters may put HttpSession object into a wrapper, so neither synchronizing on it nor using it as a key in a ConcurrentHashMap is safe :/
Furthermore, in case of "maintaining a static ConcurrentMap" solution, sessionContextAttributes would not get serialized together with its session for example when sharing between cluster nodes or temporarily storing on disk to use memory for other requests.

Instead, I use HttpSessionListener to create and store the new context as a session attribute:

ConcurrentMap<Key<?>, Object> getHttpSessionContextAttributes() {
    try {
        return (ConcurrentMap<Key<?>, Object>)
                getHttpSession().getAttribute(SESSION_CONTEXT_ATTRIBUTE_NAME);
    } catch (NullPointerException e) {
        throw new RuntimeException(
            "No session in call context. Consider either using a filter"
            + " that creates a session for every incoming websocket request or"
            + " using websocket connection scope instead."
        );
    }
}

static class SessionContextCreator implements HttpSessionListener {

    @Override
    public void sessionCreated(HttpSessionEvent event) {
        event.getSession().setAttribute(
            SESSION_CONTEXT_ATTRIBUTE_NAME,
            new ConcurrentHashMap<Key<?>, Object>()
        );
    }
}

While it is not explicitly stated in the spec that sessionCreated(...) will be called on the same thread that first created the session with request.getSession(), it is kinda implied and both Tomcat and Jetty do so. Last but not least, certain Spring utilities assume that this is always the case.
Further discussions about this: 1, 2, 3