Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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?

share|improve this question
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. – Peter Rader Oct 21 '14 at 12:24

2 Answers 2

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.

share|improve this answer

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 {

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

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

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

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 {

    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()) {
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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