Hibernate version: 3.0.5

Name and version of the database you are using: Oracle 9.2.0.4

I'm using Cocoon 2.1.7, Hibernate 3.0.5 and Spring 1.2 to develop a fairly big (5000+ classes) web application. I have a question about best practices when moving domain objects from Hibernate through my Service Layer to my Presentation Layer. This isn't completely Hibernate, but mostly...

In anyone's opinion, when it comes to Hibernate lazy loading, should the values of a Domain Object be initialized by the time it reaches the Presentation Layer? More specifically the values that the Presentation Layer cares about. I get a lot of unexpected behaviour when it comes to saving the objects after the HTTP Form has been submitted like proxies or collections that span more than one open session even though the HTTP Request was just created. I'm using the OpenSessionInViewFilter to accomodate lazy loading, but should the Presentation Layer really know this much about the Persistence Layer?

I've been thinking a lot about using Web Implementation classes that contain only initialized values, then pass those values into the Service Layer to saveOrUpdate() the Persistent Object. It's quite frustrating developing around my tools, like Hibernate, but other than using JDBC, I'm at a loss as to what to do about it. Anyone with advice on a Cocoon/Spring/Hibernate architecture?

Many thanks,
Dustin

Hi,


IMHO having unitialized proxies passed through layers out of a session is a bit like walking with a time bomb in your pocket not knowing when it is going to explode... So I cannot imagine doing it.

But I must sadly admit that I can't give any advice about the "right" way to do it - in our project we ended up copying the fields we needed from the Hibernate POJOs into the presentation layer POJOs :-(( - ugly as can be.

Erik

While I love hibernate on the server side, it becomes a nightmare once you decide to move your POJOs created with Hibernate over a tier or two. Obviously, you want your data model to be as natural as possible. So you do not want to have to modify your data model to reflect the technology supporting it (wouldn't be POJO then).

Unfortunately, unless someone knows something different, you are forced to abandon lazy loading if your object goes across a tier. Not doing so can get you into all sorts of Initialization exceptions since Hibernate's proxied collection classes require the session to exist. Obviously on a different tier, that session is lost.

It would be nice if the Hibernate collection could somehow maintain the connection to the database via the original session no matter what tier you are on, but that is probably asking too much.

With EJB3 entity beans, I believe this will go away in that you are always passing around a proxy to the real object, not the object itself. And since the real object is sitting somewhere in some container, that object has access to the database at all times. So you can load when you make the call.

If someone knows a solution around the Hibernate problem, please post and I will worship you. (And don't say architect around it)

It was dicussed many times on this forum and there are many ways to solve this problem "OpenSessionInViewFilter" is a good way too.

"It would be nice if the Hibernate collection could somehow maintain the connection to the database via the original session no matter what tier you are on, but that is probably asking too much.
"
Original session is dead after you close it and there is nothing to maintain, just do not close session if you need it open or initialize proxies and collections before to close it.

http://hibernate.org/43.html

Don't explain the same stuff over and over, that's why we have a wiki.

markricard, and others,

Do you want to send uninitializated collections to your second tier and client which you want to stay uninitialized until "further notice"? Do you want lazy initialization to happen only in the DB access tier? Are you frustrated when the second tier tries to init a collection when the session is closed, and you can't do anything about it?

We are dealing with a very similar situation with our data serialization tier and EJB3.0. The same issues are still present with LazyInitializationExceptions as in pure Hibernate. We send objects with intentionally uninitialized collections and Hibernate uncontrolably tries to load everything the next tier touches. We like lazy init, but we want to have full control of it...

We have proposed (in another thread) changes to the way collections are handled when marked extra-lazy. We are ready to make the changes and submit them to the community as soon as support for the functionality is shown by the design team. (We don't want to create an abandoned fork in the system.)

We are considering writing support to suspend further initialization until the objects are back "in session".

In this model, objects that get sent back and reassociated or reattached could proceed as usual with lazy init (wthin the Hibernate data tier) but once passed to another tier uninitialized, Hibernate would leaves them alone, and treat them as regular Java collections.

Please show support for this functionality if you want it to move forward.

Suggestions are welcome.

I do not think this patch can be accepted. It breaks transaction demarcation, "auto-load" just hides programming errors. "LazyInitializationException" is more feature than a problem, it helps to write correct transactional code. So "LazyInitializationException" is the correct way to avoid incorrect transaction demarcation and session management, there is nothing to fix in hibernate code (it is a user error).

When the application developer has decided that a session is over, it should be over. There comes a time when Hibernate really has to let go of the data and let us work with it on our own terms.

We have a tier which is no more than a object data compression layer. It is a communication layer formatting client requests and server responses for transmission over the network, encapsulated in a special packet. It uses reflection to discover object properties so custom descriptors do not have to be written for every object sent.

We send it objects from our data tier to compress and send out. Hibernate has no business trying to initialize objects when this communication layer introspects them.

LazyInitializationException IS a feature. When used appropriately, it can be very good. The problem is that the application developer has virtually no control of this feature. The feature has it's limitations - it doesn't know when to leave well enough alone.

Think about this for a moment. What if our object serialization layer were written in a language other than Java? Hibernate would have no effect on the data - would it? This is the effect we want.

Other Java software should be able to run next to Hibernate and operate on relational data in objects without fear of Hibernate's overextended reach into other code.

I believe it is better to solve XML binding problems using XML binding tools and it must be better to patch XML binding tool if doe's not support partrial graph serialization than to break ORM tool.

Please reconsider. This is not an XML solution. It's an OBJECT de/serialization tool over which we have no control. It is a commercial solution from a third party for a proprietary communication protocol we are required to use. It works very well, but it is completely incompatible with Hibernate at the moment due to our lack of control over the lazy initialization feature.

...and why don't you see this as a "complete lack of control over you commercial serialization solution".

There are very good reasons why LazyInitializationExceptions are thrown, and one of them is that "data not fetched" != null.

If you don't want lazy lazy initialization exceptons then fetch the data or null out the data on your own or even better, hook into your commercial solution and tell it to ignore associations which return false for Hibernate.isInitialized() - and then realize that these objects *cannot* be reused safely again in another session since they are now not a correct representation of the detached object graph.

It is much better that you control what you want to do in your specific situation than to make the ORM more complex and inconsistent.

Yes, this exception is very usefull, it helps to detect session management errors. It is hard to test/debug concurrency related stuff, correct session/transaction management code is very important to avoid anomalies.
It is trivial to solve partrial serialization problem (and it is usefull for any binding tool anyway) using "filter" callback inteface to control graph traversal.

Because it's not out of control. I prefer to stop problems at the source. The serialization framework is doing it's job perfectly, and Hibernate is causing interference. We have determined that adding logic regarding what gets de/serialized into the serialization tier would also be duplicative, thus not the ideal design. Why? Because our DAO logic was already written to initialize exactly what data is necessary to respond to the client, and we want to centralize the business logic. We don't need another repository of configuration data/code to maintain. We need the ability to ask Hibernate to just trust that we knew what we were doing when the data was assembled.

(Why assume the programmer is lazy or incompetent, and needs constant babysitting?)


We don't want the data fetched. This would be the equivalent of loading the entire database into memory.


This would work if there were places to hook in...


Yes, that's why we want more annotations for relationships - to specify what we want.

Hibernate already has fetch eager, fetch lazy, fetch no-proxy, and fetch extra lazy. Fetch extra lazy has the right idea, but has not gone far enough. Adding fetch "unless detached" is a natural progression of these options - which are mutually exclusive I might add.

Choosing among mutually exclusive options is not more complex from our standpoint. It does add code to the framework - where it belongs. The name of the game is rapid development. Reusable code. Modular components which fit together. Multiple tiers designed to do what they do best...

There are many others frustrated with this problem. Many just keep the session open. All this does it allow more unneeded data to load, and for performace and scalability to take a serious hit.

The fact that objects have relationships in the database is a concept to be capitalized on with object oriented software. However - sometimes you need the related data, sometimes you don't. Merely inspecting the object's relationship placeholder in another tier for the presence of data should not be prohibited. All I'm asking for is control over when to retrieve it. It's not an unreasonable request.

The serialization tier is prepared for a null relationship. It's ready for an empty Set. But iterator.hasNext() needs to retun false. These are reasonable ways to automatically detect the need to serialize a collection with no prior knowledge of the object. But Hibernate will not let it access the empty set without throwing an exception. Hibernate is just "getting in the way" in my opinion.

There is a very serious assumption made in the framework - that there is never a valid reason to access an uninitialized collection in any way.

I have no doubt you understand what it takes to lobby and cause an enhancement to happen in a commercial package. It's next to impossible.

Open source collaborative development is about becoming liberated from idealistic vendor-promoted concepts which in the field do not accommodate real-world problems, or rather create more of them. It's about making enhancements to our tools when other given limitations become brick-walls.

When our desired solution is within our reach, we will work towards it. We believe that Hibernate is overbearing with regards to it's strict mandate of forcing lazy initialization on objects which are out-of-session.

Adding "extra-lazy-with-inconsistency-on-top" is not going to make it the core of the ORM - period!

You have all the extensions point in the world with hibernate, feel free to utilize it to introduce inconsistency into your domain model. You can override the implementation of the collection, you can override how the whole engine of hibernate works, etc.

But null != data not fetched. period. end-of-story.

I don't see how data inconsistency could be introduced on an immutable object?

I'm suggesting that an uninitialized Set be able to remain uninitialized by choice, and be identified as such in the ORM across tiers. Not null, not initialized, but UNinitialized.

Think of it as an UNinitialized state...

There is something good that can come out of this if we don't run out of patience. I can see it as very interesting to have an object property even visible on the client that the Set is in this state.