Hibernate and JSP Transaction per Request_问答_开发者

Hey, I'm building a four tier software system (Presentation - JSP, Problem Domain, Application Logic, Persistence) and I want to have my transactions in hibernate per request so that I am not making a transaction every time i want to do something and also that I can have data tracking with my objects so that only the properties that were changed are updated.

I have looked at spring as a framework for this and as much as I would love to implement开发者_如何学Go this my group has vetoed it and we cannot use it.

I have also looked at JTA and I cannot see how it would be of use as I am not using beans.

I have thought about a solution such as having a method to call to close and open transactions but it seems like there could be a more elegant solution.

What would be the best way to keep my transaction per request based on my system?

Apache provides a SessionFilter for Hibernate, instructions after the click.

Hey, I'm building a four tier software system (Presentation - JSP, Problem Domain, Application Logic, Persistence) and I want to have my transactions in hibernate per request so that I am not making a transaction every time i want to do something and ...

I am interested on how'd you make your application with 4 abstraction layer, while you are using ClickServlet to maintain the one transaction per request. AFAIK your transaction will be as many requests as your active servlet worker threads.

If you want to leverage the lazy loading capabilities of Hibernate, you either:

(1) have to maintain transaction when request is still active (so that you won't get the LazyLoadingException), or

(2) you have to segregate the layer, make layer pass DTO and VO instead of passing the Hibernate model to layers above.

IMO the latter is a cleaner approach, as the main objective of having abstraction layers is to make them easier to reuse, easier to test, and separate the concern.

I suggest you not to handle transaction in the Servlet session/request level. It will make all your layer below presentation become tightly coupled with Servlet API. Usually this is not what we want when we want to have abstraction layers. So probably Apache Click framework and its ClickServlet is not the best way to do it. Spring can handle that better. If you got vetoed, too bad then.

If you don't want to use Spring automated transaction, you still can use AspectJ (or other aspect oriented programming components) to handle your transaction transparently (create transaction when entering methods and commit/rollback when exiting methods). Of course this is more hairy than just simply adopting Spring Framework.

... also that I can have data tracking with my objects so that only the properties that were changed are updated.

This one can be handled by Hibernate Level 1 Cache + Lazy Loading transparently. You don't have to do it yourself. Hibernate will only generate the SQL to the backend when session is being flushed, or L1 cache is full, or on transaction commit. In general, you don't have to do anything in order to minimize Data Manipulation Language (DML) statements to backend, usually Hibernate handles this better when configured properly.

I have also looked at JTA and I cannot see how it would be of use as I am not using beans.

You can use JPA without beans. It's just simply an API that you can invoke from anywhere.

I have thought about a solution such as having a method to call to close and open transactions but it seems like there could be a more elegant solution.

Yes. Look at aspect oriented programming by Gregor Kiczales. Spring Framework support this AOP off-the-shelf. If your team vetoed it, you can still Do-It-Yourself.

What would be the best way to keep my transaction per request based on my system?

Best approach (seing that you have planned to have 4 abstraction layers), is load your data from Hibernate domain models to Data Transfer Object/Value Object at the Persistence Layer. The layer above, Application Logic Layer has access to the Hibernate domain model, but may not pass Hibernate models into the layer above. In order to make it efficient you have to implement paginating in these layers (otherwise you will often load all data into memory, which is bad).

This way, and coupled with the aspect-ing the transaction I think is the current best practice.