Hi Ben,
One this to clarify about the Session is that its only caches POJOs within the scope of the current transaction/request. Once the transaction is committed, the session is destroyed along with the cache. One of the goals of the session cache, or level 1 cache, is to avoid repeated reads of the same data in a given transaction. This cache is the "resources" people are referring to. Since the cache is scoped to a single request/response, you can see how poorly this will perform with concurrent requests if the memory is not reclaimed.
If you want to have the cached object span multiple requests, you have two options:
1.) Use a second level cache:
http://www.hibernate.org/hib_docs/v3/re ... ance-cache
The difference here is that the L2 Cache is available at the session factory level. So if User A and User B go after the same row of data, they'll be pulling it form the same cache, and not two distinct caches scoped to their respective sessions.
2.) Use an extended session as Ananasi had mentioned. If you're using JBoss Seam and/or EJB3 Session Beans, this can be done quite nicely:
http://docs.jboss.com/seam/1.2.1.GA/ref ... tence.html
Basically, what this approach does for you is keep a Session active until you say the "conversation" is over. Even if you don't use Seam, section 8.3.3 describe the functionality.
Ryan-