On 21 Dec (11:48), Gavin King wrote: > I'm not actually sure that there are any commonly accepted > names for this pattern. The Hibernate Session is *almost* > similar to UnitOfWork except for the fact that it is _not_, > actually, an atomic unit of work. Neither is it quite like > the ODMG Database or JDO PersistenceManager which, by their > names, imply a long-lived, singleton-style object.
Uh, somehow I missed that JDO part of your message, forget my last mail... Even a prefix would help (HibernateSession is a bit long, but it really shouldn't be called just "Session" and "Transaction". While I'm at it: Another rework, or at least a discussion about it, for 2.0 would be the automatic reconnect of Sessions. You once mentioned that in a forum post, but didn't like it. My two cents: If you've learned the basic concepts of O/R mapping, it's easy to produce a real, working and maintainable two-tiered application with Hibernate. Just use lazy collections and disconnect/reconnect the Session which is stored in the HttpSession. At least for web applications, that is. If you don't require the lazy loaded collection in a Servlet call or JSP, you could even just close it and reopen it at the next call. In a three-tiered architecture, the recommended approach we currently propagate is to just open new Sessions and close them with each transaction. Some people realized that their JSP pages at the top of the system can also start transactions (by calling transactional methods on the Business Facade) and therefore open/close Hibernate Sessions in the Persistence Layer somewhere further down in the system. They immediately face the problem of lazy loaded collections: Loading an object at the "top" of the JSP page (results in open/retrieval/close or reconnect/retrieval/disconnect of a Hibernate Session) and using the accessors further "down" in the JSP will fail. So they have to either a) Delay the closing of the Session until the JSP is rendered b) Delay the disconnection of the Session until the JSP is rendered Of course this can't happen in the JSP itself, the ViewController (the handler of Views) should somehow send a notify which will magically close/disconnect the Hibernate Session after the read and the whole rendering is finished. Think about the Observer Pattern for this. So we need an Observer which listens to state changes (like STATE_TX_BEGIN and STATE_TX_ABORTED or STATE_TX_COMMITTED) in the Controller/View of the Presentation Layer. This Observer has to keep the Hibernate Session object and will manage its lifecycle accordingly. Well, I could write a lot more about that, but the result is: You have dependency in your three tiered system from the topmost entity (View) all the way down to the Persistence Layer to handle that. You'll even need SessionSynchronization for Session EJBs which have transactional methods. This whole topic is really complex and any discussion about that would be difficult, because you cannot explain the problems in two sentences or exchange 10 lines of source code that are problematic. BTW, my current work on this subject will result as a more detailed "recommended approach" for three-tiered architectures in the Wiki, and I'm currently not happy with it at all... -- Christian Bauer [EMAIL PROTECTED] ------------------------------------------------------- This SF.NET email is sponsored by: The Best Geek Holiday Gifts! Time is running out! Thinkgeek.com has the coolest gifts for your favorite geek. Let your fingers do the typing. Visit Now. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
