I am writing a web application using Hibernate, Struts & Tomcat. I have a dao layer with each dao being constructed with the current session (using sessionFactory.getCurrentSession()). I have configured hibernate and tomcat to use JTOM for transaction management.

I'm fairly new to hibernate and am following many examples, particularly the caveat emptor one.

I read somewhere that the servlet filter pattern (beginning and comitting the transaction in the doFilter() method) isn't a great approach as exceptions may have occurred after the response has been returned, and in my case processed an action forward mapping to another page, making the possibly incorrect assumption that no exceptions occurred

Has anyone come up with an alternative solution? Would I be better to write a class of my own that starts and commits transactions, rollsback, logs exceptions etc that I call myself from the struts action classes?

Yes, you must configure larger buffer to commit transaction before response is sent.

I'm not sure how I do that but is there more of an issue with completing process of a request and forwarding to a page as if everything was fine when in actual fact a whole bunch of exceptions occurred and the transaction was rolled back

http://hibernate.org/42.html
http://hibernate.org/43.html

Thanks Christian,

I've read both of these articles already. Being pretty new to Hibernate I guess I'm trying to discover the best design approach. I understand the value of the filter approach where the transaction begins upon each request, the request processing continues, then the transaction is committed and it seems a nice way to keep the transaction demarcation separate from the struts code and the dao/persistence code I have. The only concern I have is if, say, a user updates a record, I forward to a particular page as if successful, bit actually an exception occurred and the transaction was rolled back. On many pages, we want to return to the same page if an error occurred and display the error message and if all is well, forward to a different page. How can we process an action forward correctly if some of the work continues after processing the action forward?

There is a JSP directyve to set buffer size (HTTPResponse has this property too). Buffer must be large than page if you want to forward in filter after transaction rollback. Probably it is better to demarcate transactions in controler if it is a problem for you. I prefer to demarcate transactions in controler for this reason too:



But it is more convinient to demarcate transactions in filter for lazy loading stuff.

Or you can wrap the AOP transaction interceptor from the CaveatEmptor example around your actions. I'd actually recommend you get a web-framework that has interceptors built-in, e.g. WebWork. Struts is just painful and plain JSP/servlet code doesn't scale to anything non-trivial.

i'd like to know how you did it too, craigchapman1975, thanks

Well, I scrapped the filter idea and JOTM. I brought Spring into the equation and use it's HibernateTransactionManager. I created a service layer (sits between my Struts actions and DAO's) and let Spring create the DAO's for each of the Service objects, and the Service Objects for my Struts actions. I delegate my Struts actions to Spring to make this easier. I make use of Springs declarative transaction demarcation, by configuring it all in an xml config file, so there is no transactional code in my service methods. Spring intercepts the methods declared in the xml file and handles the transactions per the transaction attributes you define for these methods. I also have a pre-interceptor that catches exceptions during the commit phase (outwith my code). I translate the exception into a non-spring or hibernate exception (so my struts stuff isn't dependent upon spring/hibernate etc) and throw it back to my struts action and process the forward accordingly.

There was a bit of effort switching to this but it is paying dividends. Have a read at some of the articles on Spring. This is quite a useful one.

http://www.onjava.com/pub/a/onjava/2005 ... tions.html