I'm using Hibernate 2.1.6 and I noticed that a few of the Exception classes (specifically JDBCException.java, StaleObjectStateException.java, and LazyInitializationException.java) log error messages in their constructors. I believe this is a flawed design. It should be up to the user of a framework to catch exceptions and log messages appropriately. Every app has different requirements for logging so it's dangerous to make assumptions in the exception classes about how things should be logged. This is especially true in a general purpose framework such as Hibernate. If the exception class handles logging, how is it supposed to know about the cases where the exception is caught and recovered from?

To make this issues more concrete:
I have a few places in my app where I don't know if a lazy collection is initialized or not, so I just try to retrieve it. If a LazyInitializationException occurs, I catach it and reattach the object to a new session with Session.update(). This works great, except my log is filled with bogus error messages due to the LazyInitializationException constructor. Sure, I can modify my log4j.properties to deal with this, but I don't think that should be necessary.

So I guess I'm making an enhancement request for Hibernate 3... could we get rid of these log messages in the Exception constructors?

Here's one of the relevant constructors:


-Adam

A. You can control logging using configuration files.
B. Your design is flawed, exceptions are not recoverable.
C. Your application has random transactional behavior, I could break it easily with two concurrent client accesses.

I think I see what you're saying about the transactional behavior, but I'm building a mostly read-only reporting system. The objects that are lazily loaded will not change once they are in the DB, so I do not believe random transaction behavior will occur.

The FAQs from the forum document says in response to the question "Do I have to keep the Session open if I want to use lazy initalization?" that you can: "Reattach, by calling lock() or update() a Detached Object to a new (second) Session when a view that is rendered accesses a lazily loaded property."

So my design takes this approach, but I was relying on the LazyInitializationException to determine when to reattach the object. I realize that if a Session throws an exception it is not recoverable and the Session must be rolled back and discarded, but in this case the error occurs because I don't have a Session. So I'm a little confused when you say exceptions are not recoverable. I think as long as I'm aware of the potential transactional problems that this design should work OK. I could rework things so that I don't rely on catching the exception, and instead know when I need to open a new Session and reattach the object, but I don't see how this behavior would be any different. Am I misunderstanding something?

One reason I have this issue in the first place is my Struts Action classes were built to be completely unaware of the database. They call objects in the model-layer, which use Sessions as needed, but the model layer currently has no idea which lazily-loaded data the presentation layer is going to need. So it looks like I should either expand the model-layer interface to allow the Actions to indicate which lazy data will be needed, or I'll have to move Session handling up to the struts Action layer. Any other options or suggestions?

Personally, I think both you and Hibernate are wrong, does that make me impartial? Or equally biased? :)

Anyway, what about the Hibernate.isInitialized(Object) method?
Can you use that to check whether the collection is initialized before using it, then if it's not, do what you were doing before?

Dunno if it'll work, coz I don't use detached objects (I'm an EvilDTO(tm) user myself, so all my advice is suspect because I'm obviously crazy).