A session is like a bucket which follows the user through their experience with your web application. Objects placed into the session are stored on the server. Before a session starts following a user, it must be created. Below is an example of a session being created in the demo site:
Although any object can be stored in a session, only serializable objects can be safely stored.
The the event the servlet is asked to terminate by the servlet environment,
such as in a server shutdown, the SessionManager will save all existing
sessions on disk. When the servlet is restarted, these sessions are revived
and put back in memory. Only objects which are serializable can survive this
process, because by the definition of Serializable, they can be stored on disk. This may mean creating custom serialization methods for certain objects stored in a session. For example, a JDBC connection
cannot normally be serialized. This is because a JDBC connection has an
active network socket. However with custom serialization, a JDBC
connection or other normally non-serializable objects can survive serialization.
There is a special interface for use with objects which are serialized in a
Session. If an object implements the ContainsManagerTracker
interface, when it is deserialized a pointer to the ManagerTracker
will be passed in through the setMT method.
The secret to writing custom serialization code is to
think, "What data do I need to write to disk to recreate this
object?". As you can see in the SerializableJDBCConnection object
in the apollo code, it's pretty much the same variables passed into the
constructor.