I want to advise against setting an infinite Session Timeout. It is a very bad call, as this is one certain way to implement a Memory Leak. As a result you will have an ever growing set of 'active' sessions. Each of them have the potential to store a considerable amount of data in Session Attributes. Each of them can have additional data associated with the session (injects, resources, beans).
Your application will continue to degrade over time until you will be forced to restart.
Also I would like to state that the longer a session is active, the more susceptible it is for hacking and intercepts.
You state,
It might be a bad call but I must implement it.
Yes, a very bad call indeed, but I am glad you know. I would like to have the opportunity to provide you an alternative solution. Can you provide the reason, and maybe some code to help document your case?
Actually thinking about some real life scenario's, I had the situation where we didn't want to expire the user page with settings and information he has gathered in his session. It was a complex graphing solution that needed much input. The user will just hit refresh to retrieve the most recent data.
The solution to above scenario was to not store it is part of the session, but instead encoded in the page itself. The simplest way would be to use <intput type="hidden">
fields. You could also use embedded xml, or make it part of the URL (to make a true browser refresh work).