File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Object Relational Mapping and the fly likes Hibernate design pattern problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Hibernate design pattern problem" Watch "Hibernate design pattern problem" New topic
Author

Hibernate design pattern problem

Adam Kowalski
Greenhorn

Joined: Jul 07, 2010
Posts: 1
I am quite new in Hibernate. I managed to learn myself a bit about Hibernate but the biggest problem I have is a designing problem. I use Hibernate with Spring, which is responsible for transactions and JSF, which I use in presentation layer. I use entities which represent database records and DAOs which implements database operations (one public DAO's method == a database transaction). I use also Spring's OpenSessionInViewFilter so in my application one Hibernate Session is connected with one HTTP request, so the objects I return from business layer to presentation layer are connected to the session during all one HTTP request. Consider please example like this:

Presentation layer code (the business one is obvious I suppose):



After executing: the user1's login is bbb, because the changes made in persistent user1 object were committed during userDAO.makeSthWithThisObjectInTransaction(user2) method, after that user1 object is still attached to the session but no flush and commit operations are invoked.
I would prefer to invoke changes from presentation layer in more explicit way, because it works a bit sloppy now

Thanks for any help.

Best regards
Melmack
Kamal Wickramanayake
Greenhorn

Joined: Jul 10, 2010
Posts: 27
Your strategy in managing transactions and db interaction sessions (Hibernate Sessions or JPA EntityManagers) have surely been used by others including myself. However it's a bad strategy to manage db sessions from the presentation layer (using something like a filter to close the db session when the request processing is complete). It just requires you to take great care in coding. If you just (even mistakenly) change an entity property and then invoke another db operation, you are gone! Also, you are violating the layers pattern.

When it comes to JPA, this problem is solved by the container itself if you use container managed EntityManagers. The strategy is not to associate a db session with a web request, but to sync with a transaction (you need to use JTA in that case).

Spring itself can sync the db sessions with transactions (with JPA or Hibernate). Hibernate itself has the contextual session feature if you need. Given that you use Spring, your easiest path would be to let Spring sync the Hibernate sessions with transactions. You will use the Spring's LocalSessionFactoryBean and inject it to the DAOs. Refer to the Hibernate section of Spring documentation. Particularly "SessionFactory setup in a Spring container", "Implementing DAOs based on plain Hibernate 3 API" and "Declarative transaction demarcation" sections.

Implement good layering in your application. It will help you a lot. Doing transactional operations within the presentation code is a bad practice.

I have crisply described the issues and solutions in this article (uses JPA): Best way to use JPA in web-tier

The Spring solution is described in detail here (again uses JPA): Spring JPA web applications (JTA transactions, JBoss 5)

Even though the last URL describes a solution with JPA, you can implement your application to use the same model with Hibernate. Differences will be limited to not using annotations in DAOs to access EntityManagers but injecting the LocalSessionFactoryBean and the definition of this LocalSessionFactoryBean and a Hibernate transaction manager in the Spring config file. Instead of the EntityManagers, you will use the Hibernate Session. Rest will be identical.

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Hibernate design pattern problem