Re: [Hibernate] Road Map

[Christian B. <chr...@bl...>]

On 20 Dec (17:58), Mark Woon wrote:

> >Yes, but closing/disconnecting the Session is _not_ the real problem.
> >The problem is: How and where does the Filter/Observer get and store the
> >Session to do its work?
> > 
> >
> 
> Ah.  I'm storing it in the request attributes.  If a page needs a 
> Session, it checks to see if one already exists in the request 
> attributes.  If it doesn't, it creates one and sticks it into the 
> request attributes.  At the end, the filter checks to see if the Session 
> exists, and if so, closes it.  Isn't this a relatively simple way of 
> doing it?

It is, in a two-tiered approach. It's a lot more difficult and complex
if you are modelling with three tiers, where the Hibernate Session is
about 5 to 15 method calls in the stack further down than the
HttpRequest. It's impractical to pass the Request in every method call. 

Some applications don't even have an HttpRequest or a HttpSession,
because they are not web based ;)

You are using the Requst as a Container, that travels through the whole
system, which is OK with a JSP -> Servlet -> Hibernate approach. In
complex scenarios, you'd like to decouple this: The Persistence Layer
shouldn't know anything about the Presentation Layer (so this would be
really bad design: passing the HttpRequest down to the Persistence
Layer). 

You need a different, more abstract Container for this kind of
architecture. You'll also need a different mechanism to cleanup/close
open resources with the complex transaction handling/configuration that
is possible in a three-tiered application.

Some people mentioned that they implemented applications with Hibernate
and put them in production. I've achieved that too, but only the
classic JSP/Servlet/DataAccess Webapp. Has anyone implemented a
three-tier system with Hibernate and lazy collections yet?

-- 
Christian Bauer
tu...@in...