On Tuesday 01 March 2005 22:07, Joe Hertz wrote: > Curious as to which concept Struts/Hibernate implementers like more > for implementation: > > #1- Ted Husted's example of Struts and Hibernate. Stick the Hibernate > Session object into the httpServletRequest. Every action has a fresh > Hibernate Session raring to go if it needs it. Then again it has it > even if it doesn't but the Hibernate folks swear that this is > basically no work for the application. As if the guts of the Session > object don't really exist until it's first method call. > > #2- Hibernate's Struts plugin concept: Getting Hibernate Sessions > explicitly in action methods, but stashing them in a ThreadLocal to > not get any you don't need. If you try to get it again in the same > thread, you get the one you already had. > > I guess the implies solution here is "Rely on the thread destroy() > method to kill the Session when it aint needed no more > > #3- something else > > Since Hibernate also suggests an approach similar to #1 via a Servlet > filter anyway, I opt to do it via a Request Processor subclass. > > I'm curious how other people go about it. Anyone ever encounter a > reason they had to switch? > > -Joe
Just before I go to bed after a long work day: what the heck has Hibernate or any other Resource Tier means to do with the presentation layer (Struts)? Hibernate is just for Persistence, with the details usually isolated from the web tier by (usually several) additional layers (DAO, Services, Business Delegate and so on). Hibernate lives in the backend, business logic comes somewhere on top of that, and the web tier (and Struts is part of and limited to that) is for presentation purposes only. If you start to care about Hibernate Sessions in the web part, you should possibly rethink your architecture. -- Chris. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
