I have been looking at building 3-tier applications with a thick (i.e. Swing or SWT) client.

What I LOVE about Hibernate (and Spring) is the ability to build clean OO designs where I do not have to worry about how much of an object graph I am pulling in from the backend databases. I can set the faulting-in of objects in configuration files instead of polluting my design.

Where it breaks down is when I want to send a POJO to the client – mobile objects. I have searched the net looking for discussions of this topic vis-à-vis Hibernate but I cannot find anything.

I did see a reference to Mr. King’s presentation the TSS symposium but the video contained no content about mobile objects. Has this been an issue of discussion before and I just cannot find it?

I think it's called detached objects. You can find a great many references to detached objects and Hibernate.

If my understanding is correct detached just means that the session is closed and that you can then reattach to a new session and save the objects. But what about objects that get lazy loaded? I cannot send the proxy up to the client. I don't event think that detached objects work with lazy loading. Does my client have to know where the object graph ends so that it can make a request to the server and then get the objects back. What I then end up with is 2 object graphs that sould be hooked together but are seperated.

Well, someone has to know where the object graph ends, either your client or the server it connects to. What Hibernate does is give you a very fine-grained control over when and where the object graph is loaded. See for instance chapter 20 in the Hibernate reference manual.

But that is the point, wouldn't it be nice if the client didn't know where the object graph ended. If the client code and Hibernate are on the same VM then the client does not have to know where the graph ends.

Once the code knows where it ends then that knowlege gets spread through out the app, and if you guess wrong, it becomes hard to fix.

I don't remember the exact thread but a couple of days ago I saw Gavin (I think, it was definitely one of the Hibernate guys) respond to a similar question by saying that if you're using a rich client, it's probably best to use long-running Hibernate sessions. Just keep the session open and Hibernate will only load the data the client requests, when it requests it.

Here it is: http://forum.hibernate.org/viewtopic.ph ... 3&start=15

But that assumes that Hibernate and the database are running on the client. It does not work for mobile objects.

I've never heard anyone use the term "mobile objects" before so that was throwing me off.

This is actually a similar situation to using an EJB Session Facade layer on the back end. If you transmit the objects, you have to initialize them as "fully as the client needs" prior to sending them. There is NO way to get around the fact that you've passed the object to a different JVM.

Hibernate does have methods that the client could use to see if things were initialized before it tried to use them - Hibernate.isInitialized(Object proxy) and Hibernate.isPropertyInitialized(Object entity, String propertyName) - but I don't see how it would help your client to know that the fields weren't initialized if another call to the server wasn't going to initialize them anyway.

You need to code your server methods for very fine-grained tasks which will initialize all the fields that the given UI requires.

If you had said "not a good idea" that would be one thing, but conceptutally it seems like I should be able to hit the proxy object on the client side, travel back to the server, get the object graph, bring it back and hook it in.

Maybe non-trivial but why not possible? Then I could tune how large the graph is outside of the application.

I agree that conceptually it would be a good idea but this isn't a Hibernate issue, it's a remoteness issue. This problem is the entire reason for EJB's existence.

To a certain degree. Somehow the Hibernate proxy needs to translate to a different kind of proxy when the object go from one space to another.

It would be kinda cool to get this to work wouldn't it?


What if Hibernate read from ResultSets (read WebResultSet) and did it's O/R mapping from there? The you could run Hibernate on the client and fault objects in over the net.

I meant to say RowSet and WebRowSet...

Is it an option for you to implement Hibernate on the client now and only go across the network for your database ?

Not unless I have a direct connection to the database. I have to go from client-->web server-->app server-->database server.

Unless I missed another way.