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

Stand Alone Java App Persistence? Roland and Kyle?

 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Web deployment is all the rage, as this thing called "The Internets" has really caught on. But many people are still building stand-alone Java applications that run on the client.

In your experience, is there any one persistence framework that works best in a stand-alone Java environment, and does not run within a J2EE client container? I know many people creating fat clients in Java run into many problems controlling transactions and mitigating database access that you might not typically see in a web deployment.

Any advice for my fat clients?

-Cameron McKenzie
 
Geoff Hambrick
author
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Besides telling them to eat less and exercise more, as long as the standalone client is not trying to update more than one database in a single table, then I would recommend JPA or possibly iBATIS.

Ok then, Geoff
 
Jamie Queen
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Besides telling them to eat less and exercise more..."


Hey now, I'm the "fat client" Cameron's referring to, and as a fellow programmer, I think you know that's not gonna happen...

We're specifically working in an Eclipse RCP environment with Hibernate (currently), and we're running into a lot of problems with session and transaction management. This results from having multiple editors open with multiple persistent and/or detached objects in each one.

There's a distinct possibility that we just haven't learned enough about Hibernate to make it work properly in this environment, but we'd like to hear from the experts out there if we're even heading down the right path by using Hibernate with a client-server RCP app. We keep hearing about how "easy" Hibernate is, which is why we're wondering if we're trying to squeeze a square peg into a round hole.

Any feedback appreciated.

-Jamie
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome, Greenhorn! So nice of you to join us in the 'Ranch.

One potential problem might be keeping Sessions open for too long. In web based request, we typically open and close a Session with a given request/response cycle. So, if we're talking sub-second response times with web based clients, we're talking about Hibernate Sessions that are open for much less than a second as well. The open session in view pattern very much embraces this.

With fat clients, a luxury developers have it to keep the Session open longer, but this can present problems as clients take too long to commit their updates or changes. Perhaps closing the Hibernate Session a bit more aggressively might address some of the issues you're having?

-Cameron McKenzie
 
Jamie Queen
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cameron, I understand what you're saying about aggressive session management, and the concept feels right. I just can't figure out how to actually implement that concept. Here's an example of our Session woes:

Open a transaction, get an entity, maybe populate some fields in the UI, then commit the transaction and close the session. Now the user clicks on, say, a tree node and wants to expand an item, which translates into pulling a new object out of the original entity, mapped as a many-to-one with the original entity. Now you either a) get a lazy-loading exception, or b) have to manage a whole new transaction just to access that object. Maybe b) is the actual solution here; I don't know.

The other path (the one currently taken, sad to say) is to keep the session open, which causes the problems mentioned earlier in this thread. It also ties up a DB session and is generally a bad idea.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic