The code you added seems unneeded.
The problem here is that we must agree on how the Server will invoke your Metadata Adapter.

When I said that "you should rely on the Server to call notifySessionClose and a new notifyNewSession to your Adapter", we were talking about what happens after you throw a ConflictingSessionException. So, I mean that you should expect the Server code to behave like this:
Code:
try {
    String newSessionID = createRandomString();
    yourMetadataAdapter.notifyNewSession(user, newSessionId, sessionInfo);
} catch (ConflictingSessionException e) {
    String existingSessionID = e.getConflictingSessionID();
    yourMetadataAdapter.notifySessionClose(existingSessionID);
    String differentSessionID = createRandomString();
    yourMetadataAdapter.notifyNewSession(user, differentSessionId, sessionInfo);
}
As you can see, if you throw a ConflictingSessionException, you will receive an invocation of notifySessionClose for the existing session to be closed and then a brand new invocation of notifyNewSession.

Moreover, you should never expect notifyNewSession to be invoked with a session ID already used, even in case of page refresh.

So, please stick to the original form:
Code:
assert (! sessions.containsKey(sessionID));
uniquelyIdentifyClient(sessionInfo);
if (userinfo.containsKey(user)) {
    throw new ConflictingSessionException(-8, "Previous session termination", null, userinfo.get(user));
} else {
    userinfo.put(user, sessionID);
    sessions.put(sessionID, sessionInfo);
}
and focus now on notifySessionClose. How do you implement it currently?
As I said previously, you should ensure that it undoes exactly all that was done in notifyNewSession, which means removing the session line from both the "userinfo" and the "sessions" Map.