Hello

I've simple lazy initialization problem, but I wasn't able to find documentation about it.

I've complex POJO model with lots of bidirect accosiations. My service layer returns partially initialized subsets of this complex graph of objects. System is multi-tiered and I'm not able to use open session strategy.

Now I have this situation that other tier likes to marshal this graph to the XML-format via reflection. This causes lazy initialization exception due returned object graph is only partially initialized, of course.

My solution: travel whole object graph before marshalling and check with Hibernate.isInitialized() all association, if not initialized, then set an association to null.

The extra twist is that some of the clients are able to use the open session strategy and it's used already. Now there's situation where this strategy is not able and I've to suppress those uninitialized proxies somehow. Due the other clients I can't set those associations to null in the DAO layer, but I've to do it explicitly later...

Is this solution ok or is there better one? If there's existing documentation about the problem, please give references.

And yes, I AM rookie (= retard)

Thanks!

Difficult. I do something very similar to yours.

You could catch the lazy initialization exception and then simply not marshal the output. Chances are, if this has not been accessed when the transaction was executed, then why does it need reporting?

If your graph is really big and highly connected, you can't practially output everything all the time. So, the L.I.Exception may be a good heuristics for when to stop. Woudln't it?

Why do you have to have a common "DAO layer"? Can't you just use hibernate all transparently, i.e., just use your POJOs as you would if no persistence existed?

A part of the problem is to find right balance between different needs. Fat clients favour rich big model. Web and WS clients need strictly selected sub-graphs of model.

Open session strategy sits fine for fats clients, but for other clients my service layer returns well-selected but only partially initialized sub-graphs. If clients have L.I.E. then they're using my service badly and it's considered as bug in their code. That's our policy and it worked fine so far.

Now I've this situation with the XML marshalling. The client receives partially initialized graph and uses JAXB to marshal it to the XML. Well, client and JAXB are not awared about Hibernate and I'm not sure what's the best way to handle this thing. I'm thinking about to set all un-initialized associations just to null.

Those nulls are not problem to us. It's ok that JAXB marshals only partial sub-graph. Actually that is exactly what we want. (If there would be open session, this approuch would marshal a half of our database, and it won't be pretty).

There's nothing wrong with hibernate. All I want is explicitly suppress L.I.E. in the certain situations, knowing that we're not having fully initalized graph.

Oh well, this might be my design flaw... :(

...AGAIN! :)

Exactly my point. So, if I understand you corectly, your service layer hands down a subgraph in which all items are loaded that actually need to be marshalled. The way I would handle this is to hack in the marshalling code and catch the L.I.Exceptions to terminate the tree walking. Another option is to check before you access whether the collection or objects are initialized, there must be some way to do this.

I wouldn't set stuff to null, that seems to me as changing the object graph. You're not trimming the object graph, you're simply indicating what the limits are for the XML view of that sub-graph.

[quote="gschadow"]
So, if I understand you corectly, your service layer hands down a subgraph in which all items are loaded that actually need to be marshalled.[/quote]

Yes, precise my situation.

[quote="gschadow"]
The way I would handle this is to hack in the marshalling code and catch the L.I.Exceptions to terminate the tree walking.[/quote]

Unfortunately the marshalling code is out of my hands. XML binding frameworks work automatically providing no enhancement points for this kind of exception handling. As far I know.

[quote="gschadow"]
Another option is to check before you access whether the collection or objects are initialized, there must be some way to do this.[/quote]

That's my current solution. I travel whole object graph and nullify every (uninitialized) proxy. There is this handy method Hibernate.isInitialized(Object) for that.

Alternatively I could make a copy instead of nullifying, but I don't see any gains in this approuch either.

[quote="gschadow"]
I wouldn't set stuff to null, that seems to me as changing the object graph. You're not trimming the object graph, you're simply indicating what the limits are for the XML view of that sub-graph.[/quote]

I understand how you see this thing. I'm feeling same way and I don't see my current solution very pretty.

I.L.E. has certain function in this approach and I don't want to throw (sic) it away. I'm not sure, what's the best way to handle this XML marshalling problem, or is there any good way at all?

I am not sure it will work, but you can try use "entity mode" as parameter to return XML (DOM model) or POJO. It must help to avoid "XML binding" too. It looks like service layer can be parametrized and the same for both modes.

You meant Hibernate's own XML mapping? It sounds very neat feature for Hib. Unfortunately I'm not able to use it in our case. :(

Our model contains objects that are not persistable at all, therefore I can't use Hibernate's XML thinggy for marshalling them. There's also other reasons to use this kind of independent XML binding framework; architectural separation, web service framework integration, my religion, etc.

My current not-so-beautiful solution (nullify everything that moves) works aok and I'm fine with that. I'm just wondering is there any better practise such a situations???

Thanks anyway! :)

Thanks for bringing this up. I have been wondering about how to limit the tree walking depth, and now I see that all I have to do is close the session after having walked around enough. That's a good way.

I have my own XML marshalling code, so I can catch I.L.Es. And if I were you, I would dig in the sourcecode of your thing and hack it in 1 or 2 places to catch ILEs and stop the walking. You can override the base classes with your hacked classes. You can also offer your modification to that XML binding framework, because it's going to be useful for others later.

Open session strategy is fine for the most of the applications. There're still cases like mine, where you like to close the session and live with the object graph you have. In this case the ILEs are only thing that reminds you about Hibernate lying under the DAO layer.

My current solution works fine for me now. There's a couple of quality objectives in my project that are clear separation in the architectural level, utilizing existing frameworks and minimazing the LOCs. I try to avoid custom code whenever it's possible. I've been a sort of NIH person so far and I'm pretty tired for that. That's the reason I don't want to code my own stuff for this. There's dozens of great XML binding frameworks and I don't want to create yet another... :) By the way, what is the name of your XML project?

I'm not fan of JAXB 2.0, but with the annotations it is ok and seems to work fine with Xfire (ws framework).

The reason of my original post is that I wasn't sure am I missing something fundamental right now...

Maybe we need some kind of mechanism to introduce OXM (object xml mapping) frameworks to the ORM frameworks? Then it's OXM's responsibility to handle different kind of LIEs. Or they can tell to the closed sessions, that do not throw any LIEs but give nulls instead of them, we can live them. :)

I don't have experience JDO or EJB3, how do they handle lazy initialization situations? Do they throw exceptions too?

I'm dealing with a very similar situation with our data serialization tier and EJB3.0. The same issues are still present with LazyInitializationExceptions. We send objects with intentionally uninitialized collections and Hibernate tries to load everything the next tier touches.

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.

Please show support for this functionality if you want it to move forward. New functions to have more control of lazy init would be added, and auto-load will be supressed much of the time.

I have also given some thought to marking collections which have been detached from the session as "on hold" with regards to further initialization until the session is present.

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

Suggestions welcome.