Understanding the article may require a bit more context than was given.
The author is talking about Session objects within a Java application server (e.g., Tomcat, Weblogic, JBoss, etc.) Such a session is a funny beast. The application has to explicity ask for one during the processing of a request (which would typically be an HTTP request). This results in the generation of a session key, and the creation of a object (the "session" object) that corresponds to that key in which information that applies to that session can be stashed. The key is communicated back to the client by either session cookie or by URL rewriting (the key gets tacked onto URLs), and is presented to the server on subsequent requests. If an application stuffs stuff into the session object, that information will persist across requests.
There are two bit problems with using a session object:
In Java app server land, the standard advice is to avoid using the session for anything other than a cache, and to pass a cache key in via session cookie or URL/form parameter. This allows the application to validate the cache, and to rebuild the cache if the session has timed out, or if the server has been restarted while the browser user wandered away for coffee. This advice isn't Java-specific. In any system that keeps sessions that can be timed-out, it's unsafe to do anything other than use the session object as a cache.
<code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>