Question

Good day!

I am modifying some codes from an existing program.
Before the program begins, they initialize all the dropdown list and store it in a session.

Is it okay to store the list of my dropdown menu in a session?
Note: the list is from the database.

SAMPLE CODE:

           HttpSession session = request.getSession();

        session.setAttribute("accountList", accountList);
        session.setAttribute("contractorAgencyList", contractorAgencyList);
        session.setAttribute("employeeStatusList", employeeStatusList);
        session.setAttribute("movementTypeList", movementTypeList);
        session.setAttribute("positionLevelList", positionLevelList);
        session.setAttribute("positionRoleList", positionRoleList);
        session.setAttribute("practiceCodeList", practiceCodeList);
        session.setAttribute("projectUtilizationList", projectUtilizationList);
        session.setAttribute("siteLocationList", siteLocationList);
        session.setAttribute("taxStatusList",taxStatusList);
        session.setAttribute("turnoverTypeList",turnoverTypeList);
        session.setAttribute("projectList",projectList);

Are there other ways to do this? If this is the most common way to do this, then How can we avoid the session from being lost?

Thank you.

Answer 1

Are there other ways to do this?

Yes, but that would depend on how long you want the values to be stored. In a Servlet container, you typically have access to Application scope, Session scope, Request scope and Page scope. The first three can be accessed in both servlets and JSPs, while the last is useful only in the context of a JSP.

If the contents of the menu can be reused across sessions, it is better to store them in application scoped objects, via the ServletContext interface.

If you do not need the menu data beyond the current request, then you ought to make it request-scoped, and not session-scoped.

If the scope of the drop down menu is however, restricted to a session, then it is a better idea to store it in a session as long as the object does not consume a lot of space. Keep in mind, that the size of the objects stored in memory will affect performance of the site, especially when a clustering and session replication strategy is in place – this is primarily because the contents of the session have to be serialized and stored for the possibility of creating a different session on failover.

Also, performance will be affected even if you are not employing a clustering and session migration strategy, as each session will consume memory that will be released only upon the next GC cycle after session invalidation.

If you wish to avoid using sessions to store session-scoped objects, you can query the data from the database on an as needed basis. Or even store the contents in files (as long as they are not confidential/sensitive data), which can make your session migration strategy a bit more painful.

If this is the most common way to do this, then How can we avoid the session from being lost?

I didn’t understand this part of the question. In any case, sessions are managed by the container on behalf of the application developer. At most, a developer may specify the session timeout values that will dictate the extent of the rolling-window for session expiry. The developer may also invalidate the session at some significant point in the application’s navigation flow – for instance, on click of a logout button. The developer typically does not need to worry about managing the sessions, beyond what needs to be done using the HttpSession API, or entries in the deployment descriptors.