• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Hibernate: long-lived session

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Scenario: images are stored in the database and retrieved by calling a servlet and passing an id.

Using Hibernate, is the answer as simple as creating a session and storing it in my servlet, then continue loading Pictures into it and get a lightening response as previously retrieved images will be cached?



would I perhaps need to close the session in destroy()?

could the session get really huge and crash my server?
 
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I remeber having read that Hibernate Session should not be reused.
So you have to close the session well before the destroy(). Infact in a finally block in the doGet() itself. But ofcourse you might cache the returned images in the HTTPSession if they are frequently accessed and you want fast retreival.
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can reuse the Session if you need to. A Session is after all supposed to map to a business transaction, which may have multiple DB operations. There is a pattern called the ThreadLocal pattern described on Hibernate's website where a Session is basically opened and kept in a ThreadLocal object for reuse within a piece of work.

Remember that Hibernate comes with its own caching arcitecture. The Session is the first level in that architecture, but is only ever meant to relate to a single business transaction. You could use it as you describe though - but you will have problems if the number of objects in it get very numerous (as you would if you tried to return a big resultset in one Session). Hibernate suggest caution doing this - largely because of stale data worries. You should never hold on to DB resources for a long time (as a Session used in this way would) so you'd have to ensure that disconnect() is called. The best strategy for "application wide transaction" as you describe is to open a Session, store it in the HTTPSession and reconnect()/disconnect() per request.

There is always the second level cache - which is specifically designed for relatively unchanging objects, which I imagine your images will be. The advantage of using this is it will be configurabvle with the cache policy (see the mapping docs for examples). You can tell Hibernate the max number of objects to allow in the cache, and it will start throwing objects out of it if the max is reached.
[ August 04, 2004: Message edited by: Paul Sturrock ]
reply
    Bookmark Topic Watch Topic
  • New Topic