I am trying to intercept the initialization of a proxy before it is loaded from the database by the cglib layer. I need this notification to potentially reconnect our long session before trying to load the object data, but the proxy initialization code does its own checks and throws an:


before things can get very far.

(Before being flamed I will just mention that we then keep this database connection (and transaction) going for the rest of the request, and then give it back to the pool. The reason for not getting the connection at start of every request is that many requests do not need database access.)

So my question is if there really should be an event in Hibernate that signals when a lazy object is being initialized, but that does not require that the lazy object's session is already connected?

Or if not, does anybody have another solution to this? (That is better than explicitly reconnecting the session before every potential lazy object access.)

Best regards
Mike

Hi,

I've tried every single pattern to manage transactions and it all came down to this.

1. Your workflows (use cases) have to be well defined so that the objects used who are containing lazy collections are initialized before any business logic.

ex. You have the Foo entity with a lazy collection of Bar entities. In a given sequence of operations by the user (workflow), you know that the Bar collection will be accessed. When you fetch your Foo entity for the first time, explicitely initialize it's Bar collection.



2. Do not try to keep sessions opened. Dead locks will happen.

I suggest to use the @Transactionnal annotation on your service layer interfaces so that Spring knows when to open and to close sessions. As for the special cases where more than one service call is necessary, use programattic transactionnal management.

This way, you can defined a fine grained strategy and decide when an operation has to be transactionnal, what are the access rights, and on which Exceptions an automatic rollback is necessary.

Trying to reconnect collections to a session is a huge pain in the a$$. We've tried that and refactored because it gets WAY too complicated. It costed us 2 months on the project, but now we're glad we used this design pattern.



3. Don't use the OpenSessionInView pattern.

Just don't use it. It's not a solution, it's just a patch for a poorly designed application. Spend more time analysing your workflows and initialize your business objects accordingly.



Hope this helps. And I hope it's not too late to refactor !

Cheers !



Don't forget to rate !!

This is horrible advice. The extended persistence context (OSIV) is probably the best Hibernate pattern, it's very flexible and powerful. There is no replacement for it.

If you don't understand it, read a book:

http://www.manning.com/bauer
http://www.manning.com/bauer2

If you don't want to implement it but need it out of the box, use a framework that really supports it:

http://www.jboss.com/products/seam

For the original poster: Whenver you have the feeling that you need to intercept proxy initialization, you are heading down the wrong track. Take a step back and rethink what you want to do. Read the docs again, read the Wiki pages about transactional patterns, read a book.

@luc

I have also tried most of the patterns with Hibernate and I have to disagree with you, we are very happy with the "long" sessions (OSIV) in our scenario (webapp with well-defined logic for when to flush/clear the session).

@christian

I guess from your answer that I shouldn't be holding my breath waiting for this interceptor event feature to become available ;-)

> Read the docs again, read the Wiki pages about transactional
> patterns, read a book.

Well, have already done precisely that and saw the comments about "every month someone suggests to open/close a new session for each proxy initialization", which is of course no good at all.

What I have here is different - reconnecting an existing session on demand - and is not really discussed in any of these places (not in your HiA book either).

Reconnecting the long session for every request makes no sense for us, but would solve the problem. I will probably either go for a solution where I partition the request paths into db-related and non-db-related so the OSIV-filter can make the right decision, or I will explicitly call upon session reconnection in the applicable business methods.

Best regards
Mike

What does that mean?

Oh, now I get it. You need a more flexible persistence context handler than a servlet filter. You basically want the request processing model of JSF (http://java.sun.com/javaee/5/docs/tutor ... ecycle.gif) and the interceptors and the extended persistence context handler of Seam.

You don't want to intercept lazy loading.

Btw, I've written about exactly this in the bonus chapter of Java Persistence with Hibernate, which should be in the final ebook in about 2 weeks and in print in about 4 weeks.

Thanks for the pointers, I will look into them to see if I find a match. And yes, I will be buying your new book when it comes out - but it would have been great to have had it a month ago as we have done a lot of our infrastructural Hibernate design already...

Best regards
Mike