Madhav Bhargava schrieb:
[[Madhav]] If you look at the tomahawk code, then you will realize that
the savestate also uses the session to store. However it takes the
entire responsibility of putting the state in session and then removing
it as well.
The general feeling that developers have got is that I am not using the
session, but is it really true?
Not entirely true, savestate uses the jsf save and restore mechanisms
which are inherent in any component, it uses the session if you set jsf
that way it uses different mechanisms.
Storing into the session is the most performant way, but there are other
storage locations for the jsf savestating.
(Client side for instance does not store into the session at all)
Many app servers already serialize the sessions, so you have to
implement a serializable on sessionly stored objects one way or the
other anyway.
The main advantage of savestate over a pure store it into the session
and recycle it is, that you do not have to take care of the garbage
collection yourself, once you hit a condition without savestate the
object automatically is removed from the storage.
But I really can recommend have a serious look at the scope component it
works very similar but is much more advanced.
