Hello,

this must have been asked many times before, but I wasnt able to locate any document that sufficiently answered the few questions I am listing below. So please bear with me.

We are implementing a "rich client" app that talks to a stateless session bean facade on the Server, and are thinking about using Hibernate in this scenario both on the client and the server side.
The idea is to call a server-side service that loads a given object graph from the database and transfers that to the client. On the client, the graph will be displayed and modified, changing existing objects and adding new ones. We are not sure whether we will require lazy loading of relationships, but if we do we would have to intercept the calls and direct them through our service layer.
At the end of a user transaction, we would want to transfer the session data back to the server in one call and have hibernate process the changes there. Now to the questions:

- Does Hibernate support this configuration out of the box?
- Any experiences, caveats and the like?
- How about the amount of data transferred between client and server (both ways). Are there ways to minimize the volume (at times we're on 64kb). I would really like to use the mapped domain objects on both sides, and not implement parallel DTO class hierarchies or anything similar.

I look forward to any hints.
TIA,
Christian Sell

Appart from 1 stuff, it's fine.
You can't out-of-the-box implements lazy loading calling your services. You'll have to build a client side service using proxy to redirect to your service.
About amout of data, it depends your object size and the number of exchanges you planned : but using client cache decrease it a lot.

thanks for your reply. I wonder, however, how Hibernates bytecode enhancement plays together with this. Wont there be a problem because on the client classes may not have undergone the enhancement?

Am I correct to assume that it would be the session object as a whole that gets transferred for the commit?

thanks,
Christian

You must not transfer the session in the client side. and any proxied classes access will raise a Lazy. your service layer have to remove the Hibernate proxy, and add it's own.

hmm, that does not seem to answer my main issue. I want to retain the change tracking features of Hibernate while the object graph is processed on the client. Upon commit of the user transaction on the client ("save button"), I want to transfer the object graph back to the server and have hibernate recognize the changes and process them as it would with a transaction in the same VM.

Ideally, I would also want to be able to perform a "rollback" (i.e., "cancel button") on the client and have all objects set back to the initial state.

can I do this with Hibernate?
Christian

Bytecode enhancement is used to provide lazy loading. If you want to pass your objects directly to a client, lazy loading doesn't make any sense... the client doesn't have a connection to the database.

So, just don't use lazy loading (which won't work anyway) and you'll be able to send your collections to the client. Note that the client's RMI will need access to some Hibernate classes.

FYI if you want to undo on the client, you've got to do work. This kind of thing isn't supported by Hibernate directly.

Ok, so I take this to mean that I cannot transfer changes made on the client to the server in one bulk, but instead have to track them myself or sort them out programmatically on the server? If so, Hibernate does not buy me much, as the mappings are rather simple, and already implemented as DAOs.

No, you talked about client lazy loading and I answered.
But If you forget that point.
Hibernate provide a detached object feature allowing you to reattach (and save) any update made to an object graph using saveOrUpdate(). No need to manage it manually.
To optimize this feature, Hibernate recommand the usage of optimistic locking (using version control): this is of course transparent for you.

that still leaves me wondering how changes are tracked between client and server.

As an example, lets say I load and transfer 20 objects to the client. On the client, 5 of them have simple properties modified, 3 new objects are created, and relationships established between the new ones and the loaded ones.

Now, how do these changes get recognized on the server? If I get you right, I would have to track the changes on the client, send the 8 modified objects back to the server and then call saveOrUpdate for each one individually. Looks rather manual to me.

thanks,
Christian

You create the new objects and relationships on the client, you send the graph back to the server and you call session.saveOrUpdate(node) and Hibernate will check the graph using the "cascade" settings of your mapping definition (walk up and down in the graph). It will recognize new instances by looking at the identifier value (or version number or using a custom Interceptor) and INSERT them. It will recognize old "detached" instances and UPDATE them if neccessary. Hibernate will perform a version check, if you provide a version column in the database.

forgive my insistency, but that still seems to leave me with the duty of determining the root node from which all updated/created object are reachable. If, for example, the object set transferred to the client has multilpe non-related graphs, I will have to pick one object from each graph for transferral back to the server. And if I create new objects that are unrelated to previoulsy loaded objects, those have to be individually sent to the server as well (right?).

I mention this because I have previously come across other frameworks that allowed me to extract the change set from a transaction and send that over the wire to apply it remotely. I hoped Hibernate would offer a similar capability. I still think this was a handy feature.

regards & thanks,
Christian

Hibernate doesn't do that. We are not really a GUI data binding framework also.

humm.. I am not sure what you mean by a "GUI data binding framework". As far as I can tell, nothing of what I said was related to GUI - on the contrary, I was looking for an easy way to transfer object changes for processing on the *server*.

I may look into extending Hibernate, or creating an add-on, that implements my requirements. I would also like to see synchronized 2-side relationships (i.e., if you say "parent.addChild(child)", "child.setParent(parent)" is implied). I guess this is another thing that hibernate does not provide.

regards,
Christian

A GUI databinding framework would know what arbitrary objects changed and have to be propagated back to the middle tier (and then updated/inserted by Hibernate). There is also a good reason why Hibernate doesn't provide "managed relationships", as this would break the POJO semantics. We recommend to enforce association references in accessor methods.