Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Hibernate Sessions in a Swing app

 
dave taubler
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm still in the learning phase of Hibernate; having gotten the basics down, I've moved on to figuring out some best practices.

The sample app them I'm using to explore Hibernate is a Swing app. I know that in the real world, most Hibernate apps I'll encounter will likely be web apps, but hey, this is how I decided to learn! That being said, I figured I should approach my sample app as if I want to implement it correctly for what it is: a potentially-long-running desktop app.

A primary difference between my app and a typical web app is the lack of request/response cycles. So I feel like I'm approaching unchartered territory when it comes to managing my Sessions. In a webapp, it seems that typically one Session per request/response cycle would be used, with the Session being closed thereafter. Entities wouldn't tend to linger in memory for too long; instead, the request would cause them to be fetched from the database, and the response would [resent them to the user. Session done.

With my Swing app, though, my entities will stick around in memory for quite some time. I'm trying to follow the recommendations of my (web-app-oriented) tutorials, and closing my Sessions after doing something meaningful (e.g. reading from or writing to the database). But I find it hard to avoid certain errors. For example, at the moment I am experiencing this one:

org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: [com.me.movies.model.Movie#1]

when I call session.saveOrUpdate() on an existing Movie entity, that I had originally read from the database via an older, now-closed Session. I suspect that the new Session isn't aware that the Movie already exists, and thus is SAVEing rather than UPDATEing.

I've also been playing whack-a-mole with these guys:

org.hibernate.HibernateException: Illegal attempt to associate a collection with two open sessions

So with all that, does anyone have any best-practices for Hibernate Sessions with apps such as mine? Should I still be striving to close my Sessions after db reads/writes? Or should I consider the lifecycle of my Swing app to be equivalent to a session, and therefore open and reuse a single Hibernate Session for the life of my app?

Thanks in advance for any advice.
 
Edvins Reisons
Ranch Hand
Posts: 364
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The reason behind the practice of very short sessions in a web application is that a limited number of available sessions/connections has to be shared among a number of concurrent clients. In your case of a desktop application, this does not apply, and maintaining a session for a use case, or even the entire application, may help you keep it simple.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, in five words or less.

No.

Just Kidding.

OK, so my approach is the same no matter what the front end is. Because you might at some time want to swap out a different UI, and if it is all based on the UI and coupled, or designed differently for different types of UI, that swappability is long gone.

I am sorry, but I am trying not to spend 5 hours on this post, as your thread is very big.

So some basic rules.

1) Sessions are cheap to create.
2) Keep Sessions as short as possible, because the longer they stay open, the more responsible you will be for the objects created, managed by the Session so you don't run out of memory.
3) Use DAO patterns to keep you Hibernate/Database interaction seperate from the rest of your applications.
4) Understand about detached objects, as you will have lots in this app.
5) NonUniqueObjectException get thrown when you have a detached object say with id=5 and there is already an object managed by Hibernate in a Session with the same id.
6) With detached objects, implement equals and Hashcode and read up about Hibernate's Optimistic Locking.
7) Is you have a Swing UI and then just Hiberate DAOs, know that you are using the old-fashioned two-tier approach.
8) You might consider EJB 3 and SLSB, they are Pojos, so they can be called through a container, directly, through JSP/Servlets, and Swing apps. But only use them as EJBs if you have to have transactions and security handled for you.

Hope that helps

Mark
 
dave taubler
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the responses; they help a lot.

I suspected that a solid understanding of detached objects would be important, so that will probably be the next area that I explore. Also, Mark, your point about swapping out UI implementations is well-taken; in fact, at some point I'm figuring I'll work it into a web application anyway.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic