struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Bollmeyer <j...@christianbollmeyer.de>
Subject Re: Hibernate and Struts Usage Pattern question/survey
Date Tue, 01 Mar 2005 21:54:57 GMT
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message