3

I tested two approaches to store session data:

  • The classic: 1 key, 1 object (And every key as static final String in a class)

"user" --> UserObject

"preferences" --> List

...

  • An approach with only 1 object

"sessionObject" --> SessionObject

And my SessionObject contains UserObject and the list of preferences as attributes. This is a fairly simple example but imagine it with 20+ attributes.

The advantage I see in the second approach is that :

  • You only have to delete one key to ensure session is empty
  • You don't have to create the bothersome set of final static String to create the keys
  • You'll know what type of object to retrieve (Using key you have to cast)

Do you see any problem I might went over? Or does anything go against best practices?

1
  • In the session you shall not put instances of classes that are not part of the container/runtime/jdk. You can not balance work between different hardware-servers and/or (tomcat/jboss/glassfish/beaweblogic)-context's. Also passivation and activation of sessions may compleatly fail.
    – Grim
    Oct 21, 2014 at 12:24

2 Answers 2

1

1 key, 1 object will be more predictable regarding interaction with app server and possible session replication techniques. Not sure what you mean by "set of final static String" being necessary. You may manage session keys any way you like.

Consider you have 20 preferences, and perhaps your preferences class has an enum of preference names. Could get/set session a little bit indirectly:

class Preferences {

    private static final SESSION_KEY_PREFIX = Preferences.class.getName()+'.';

    enum Name {
        LOCALE,
        ...
    }

    static String get(HttpSession session, Name name) {
        return (String)session.getAttribute(SESSION_KEY_PREFIX + name.name());
    }

    static void set(HttpSession session, Name name, String value) {
        session.setAttribute(SESSION_KEY_PREFIX + name.name(), value);
    }

    static void clear(HttpSession session) {
        for(Name name : Name.values()) {
            session.removeAttribute(SESSION_KEY_PREFIX + name.name());
        }
    }
}

You may then add preferences by just adding to the enum, and all specific interaction with the session is encapsulated.

This example pretty trivial so the Preferences class itself could also become an enum instead, without a separate "Name" enum. Which could be:

enum Preference {
    LOCALE,
    ....;

    private final String sessionKey = Preference.class.getName()+'.'+name();

    String get(HttpSession session) {
        return (String)session.getAttribute(sessionKey);
    }

    void set(HttpSession session, String value) {
        session.setAttribute(sessionKey, value);
    }

    static void clear(HttpSession session) {
        for(Preference pref : Preference.values()) {
            session.removeAttribute(pref.sessionKey);
        }
    }
}
0

For those having the same question : In Application Servers like Weblogic when doing clustering and session replication. The session is copied to other servers when its modified. To trigger this copy, it seems that the server checks the references of the objects in the session and once it detects a change replication is done. So using only one object containing other may prevent the copy to be triggered.

Not tested.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.