This content has been marked as final. Show 4 replies
You could dump stuff in the session, or you could just fetch it when you need it and then forget about it again. Me - I tend to go for the latter nowadays. To less you have to keep track of in memory, the less chance you have of that information going out of sync. Machines nowadays have plenty of resources at their disposal, you don't have to cache stuff to save some CPU cycles. Bearing in mind there are exceptions to every rule of course, when it takes a good deal of time to fetch data (like from a web service), it might pay off to cache it. But then I'd use a proper caching solution and not the session.
This is one reason to use CDI. Your bean scopes become more flexible (you can even create new custom scopes) and their life cycles are transparent to their users.
Read this article from where it says "the C in CDI" onwards ,http://www.oracle.com/technetwork/articles/java/cdi-javaee-bien-225152.html
Most likely not applicable for this situation, but one alternative to session variables are cookies.
If the data that you want to share on multiple pages are not related to the user or client then storing data in the session is not the ideal way because when session is destroyed the data is destroyed and you have to fetch the data again with the new session so store the data in the servlet context object . context will not be destroyed until you shut down the application so one time fetch will be enough. If the data is related to the client or user then the better option is session.