HTTP Session vs Stateful session beans
843841Jan 8 2006 — edited Jan 8 2006It seems to me that the J2EE platform has two competing solutions for storing client state: Stateful session beans and HttpSession parameters
or in other words
Which tier to store the state - web tier or ejb tier?
Most architectures choose to use stateless session beans and store the client's state in the web layer's HttpSession. The advantage is that the JSP layer doesn't have to message a session bean to get its state and stateless session beans are widely documented as scaling better than stateful ones.
However, stateful session beans are architected for just this purpose. As containers get more sophisticated, it stateful session bean could be a lot more efficient at caching state than HttpSession.
For example, in the 2.0 EJB spec, it mentions that the EJB container VM could be smart enough to map the beans state from memory directly to disk [during passivation], avoiding the overhead of serialization.
So, in the long run, having the web layer stateless may be more scalable than having the session layer stateless.
I understand it may vary upon requirements as well. We have a main screen from where a user can go to multiple sub screens. But to save data he has to come back to the main screen and save data. (Enters person data in main screen, address, telephone etc and other data in the sub-screens)
Any pointers to white papers or technical articles would also be helpful.