I am trying to come up with a strategy to use a Filter to close and commit a session from ThreadLocal after each page request. The filter launches a servlet, which put some objects such as persistant Collections and other objects into the request object, and then forwards to a jsp page to use these objects to draw the output HTML page.

At first I ran into the following problem. I had a few instances where inserts and updates failed for various reasons. However, since the JSP was already rendered and sent back to the client, the client was never informed of the error! Once the response writer sends back data it is too late to redirect the browser to an error page. So the user thinks that everything is honky-dory when in fact there was some error!

So I changed my structure so that the JSP is only rendered after the session is committed and closed. The problem now is that I cant use any lazy-loaded collections (trying to do so throws an exception). I know I can do Hibernate.initialize() on them but I would rather avoid this, as it is annoying and error prone to remember every instance where a lazy loaded collection would be needed.

Anyone have any ideas on a good a good approach to using Hibernate with a web app? In summary my goals are:

1) is to avoid needing to explicitly commit in my code, I would just assume one transaction per page request.
2) To be able to redirect to an error page on some persisting error
3) To to be able to display from lazy-loaded collections in the JSP.

Is it even possible to do what I have in mind?

Thank you,
Daniel

I would consider using some MVC approach.
( webwork is a good framework for this task )


FIrst phase of request is action invocation, and action knows whether it went OK. The it redirects to the view page ( in the same http request ) which is rendered. Use thread-local session pattern.


Filter commits transaction then. Only problem is using blobs/clobs,
which can not be read in the same transaction as they are created.

placing your action logic in jsp is wrong approach - you can not test this logic outside webserver, it's damn diffucult to debug, and performace is well, suboptimal.


webwork + velocity combo is far better...

I am not sure how using that approach solves the problem. When you say "The it redirects to the view page ( in the same http request ) which is rendered", as it is rendering it will need to use lazy loading at that point. If the transaction is already committed and session closed at that point then I can't lazy load.

Let me give you an example of what I am trying to do. It is something like a page that inserts something (say the name and address of company to go into a Company object), then displays an invoice along with along with line items. (The newly inserted company is associted with the invoice). What happens is thus in my current pattern:

1) The servlet inserts or the company and loads the Invoice persistant object and places it in the request object.
2) The filter commits, closes the session and forwards to a specified jsp page.
3) The jsp displays the Invoice and lazy loads the line items from the Invoice object and displays them.

The problem is though that by (3) the session is already closed!

Using MVC would still have the same issue. What would happen is thus:

1) The action inserts the company and loads the Invoice persistant object from the model and loads a bean or some object with it.
2) Action commits and closes session.
3) When the action "knows" that it went well it renders. But the rendering process still needs a lazy loaded collection!!

Could you please clarify how this would work?

Thanks,
Daniel

We talked about this some days ago and it seems that this is a problem with the Open Session in View pattern (the ServletFilter you are using).

The thing is: I never had problems like this. If an "persistence" error occoured in my JSP, my error page would show up. I've mapped the Exception in my web.xml to the error page location. I guess it depends on the flushing of the response to the browser, but I never got half rendered pages, even with hundreds of kilobytes in my response. I don't remember when the buffers get flushed in Servlets, so you might have a look at this.

without introducing mvc, did you simply try to enable jsp page buffering ? this way you should be able to redirect on error even if page rendering is started

Also, I think you stated that in your MVC idea the filter would commit after the view is drawn. But this still doesn't solve my problem, as once you start drawing your view it is too late to redirect to an error page if the Company insert did not work for whatever reason.

(Side note: not to get into a whole discussion on MVC now, but note that my filter pattern is MVC-like. The filter acts as the "action"and loads the servlet which acts like the model and the request object acts like the bean. All logic is done there but no view logic. Once contol goes back to the filter (which acts as the "action") and sees everything is ok it directs to jsp which is the view. The jsp does nothing but display the data that is placed in the request object, no logic goes on there.

Also, the servlet actually uses business objects similar to session beans, not load data directly.

As you can see this is simply modified MVC. But as a said, this is not my main point of starting this thread)

You should be aware that lazy initialized ( not yet lazy initialized )
collections become useless after sesison they were created in
is closed. ( As well as proxies )

So, if you know that you need your object after closig session, best solution would be to load it again.

( bad for performance - second trip to database )


Anyway, hibernate does really nice fit into web scenario
( regardles with MVC or not ):

1. Open sesion on start of request ( via filter, store
sesion in thread local )
2. Do whatever necessary, insert remove, load, save...
3. Render page.
4. close / flush session ( viea the same filter )

if you do #2 in servlet, and then you do dispatchRequest - it's not
real redirect, it's the same request with subrequest ( and if you
are carefull, your filter will see that, and will not open yet another session ) - so after servlet redirect session is still in place
and object is usable.



I do following:

1. Session is opened ( and transaction started ) in filter
2. action executes, and issues flush to catch eventual problems
3. internal redirect to view, rendering ( does not work for blobs
/ clobs )
4. filter commits transaction and closes session.

This is not quite true. In Hibernate 2.1 you can lock() an uninitialized object in a new session, and continue working with it as before.

That's cool. Only problem is that this not gonna happen
automatically :)

It would be major PITA in my view layer to
1. catch LazyInitializationException
2. reattempt the operation.....

For now I just reload object in question in my swing
application before I try to do something menaningfull with it
by means session.load() - peformance is acceptable....

I don't see the need to redirect to the view. Using Struts, I always forward to my JSP, which then has full use of the request. Your filter can do something like open session for initial servlet request (this was probably a redirect), disconnect session at end. The intial Servlet forwards to a JSP request. The filter sees the JSP request and reconnects the session calls the jsp servlet and closes on end.

Struts does just internal redirect from action class, to view page
Webwork does the same....

So it's just the same request - so why open second session.

Was this directed toward my response? It must be since I was the only one to mention Struts. I don't see that I said to open a second session. I did say that you could disconnect and then reconnect the session (implying the same session).