I'm starting off on my 2nd project using Hibernate, but it's the first that I intend to use EJBs. Basically, my application will have a web presentation running probably in-VM with the application server and also have a Java application running as an alternative interface. Most of the access will be done through the client application, not the web site.

Being new to Enterprise Java Beans and distributed applications like this, I've been doing some reading in the design pattern books. Some of the patterns are written to overcome the problems of NOT using an O/R system and therefore some must be unnecessary and counter-productive in the context of using Hibernate.

What would be invaluable to me would be if someone who's had experience writing an application like this with a remote client could give me some advice on how best to fit Hibernate into the picture.

I see several possible strategies, off the top of my head.

1) Keep Hibernate inside the application server entirely.
This would place the Hibernate Session object, in particular, entirely on the server side, thus completely hiding the use of Hibernate from the client. I could send my persisted objects back and forth between the server and client as the client needs them and updates them.
This seems like the simplest solution, but it has some obvious flaws, in my mind:
Foremost seems to be performance. I could not take advantage of any object caching on the client side and will inevitably be moving some data back and forth multiple times.

2) Send the Hibernate Session object to the client side.
First of all, I'm not entirely sure how this would work. I believe Hibernate can work like this, but I'm not entirely sure how. I would want the session cache to exist on the client side and work with a distributed 2nd level cache.
The problem I see with this, is it would be difficult to keep domain (read: business) logic on the server if the client was obtaining persistent objects directly through Hibernate.
One way I can see around this would be to have the server only ever pass object references (primary keys, for example) to the client and have the client load these objects from Hibernate. Any simple property changes to the persistent objects that can occur without the oversight of the server could be done directly from the client. Any more complicated logic could be passed to the server and the server would make the changes on its own local copies of these objects. It might even be sufficient to have the client NEVER make updates directly to the Hibernate session and instead pass all updates and inserts to the application server.
Could I assume that the distributed 2nd level cache would keep things in sync between multiple clients while not forcing me to throw out all cached data on all clients any time a change was made?

Is there another solution that I'm not looking at that you might advise?

Thanks.

You cannot move the Hibernate Session to the client. It is not serializable etc. So your option 2 will not work.

My suggestion is that you think about a command pattern that has serialized objects (Hibernate serialized POJOs or XML) + the command related data going back to the server, which returns response objects. RMI or SOAP may be also good to explore.

Cheers,


Sherman

As I tried to explain before, moving complete POJO hibernated objects between the app server and the client every time the client wants to read objects that are persistent will not be acceptable performance-wise. The client will rarely be on the same machine as the server and occasionally will even be on another network. This will be an interactive client and responsiveness will be important.

After some reading, I believe what I am going to attempt to do is as follows:

I will set up a local copy of hibernate on the client-side. The server will have its own instance running inside the application server. The client-side copy will be READ-ONLY. In fact, I plan to avoid even performing actual queries (find()) themselves on the client-side. Instead, the application server will only ever send identifier (primary key) values to the client. The client instance of Hibernate can then load (and CACHE) objects directly from the data-source. Since updates and inserts will be far less frequent than reads on the client-side, it is acceptable to serialize and ship new and updated objects to the application server and use its instance of Hibernate to persist the new/updated objects. Using OSCache should allow me to keep the caches of the clients consistent with that of the server.

Actually, scratch that idea. As I was writing this, I thought of something perhaps better:

If all I'm going to be doing on the client side instance of Hibernate is to use it as a cache, how difficult might it be to use OSCache's APIs directly on the read-only client side and have the server's Hibernate-connected instance of OSCache serve as the cache master?
For example, let's say the client wants object A. To start off with, the client has an empty OSCache that it is utilizing directly (without Hibernate). The application server has an empty OSCache that is connected through Hibernate. These two OSCaches are configured to both subscribe to the same JMS Topic.
First, the client checks its local OSCache for A and doesn't find it. It then requests object A from the application server. The application server loads object A. This implicitly places it in the application server's OSCache. It then serializes and sends object A to the client. The client places this object in its OSCache, then displays it to the user, for example. An external force then causes the application server to change object A. The application server's Hibernate-connected OSCache is notified and the notification is passed over JMS to the client-side OSChache, which invalidates object A on the client.

Does this sound reasonable, or does Hibernate interoperate with OSCache in a manner that would make it difficult for a 'plain' OSCache to interoperate with?

This seems to give me all the benefits that I want:
1) Changes to persistent data MUST happen through the application server
2) Access control to business objects will still be centralized within the application server
3) Business objects may be cached on the client side, EVEN between invocations of the client, so long as OSCache was configured to use the disk and a synchronization routine was invoked at client startup to invalidate stale items in the cache.
4) Database activity would be minimized since the application server could serve its own cached instances of persistent objects to the client.

I would probably need to set up a method for the server to decide if it should send full objects or only identifiers as the result of a query so that it can avoid sending objects to the client that it can be pretty sure are already cached. If the objects aren't cached, the client would have to make a second request to the server to retrieve the objects it's missing. This doesn't seem to bad, though. I see no reason why the server wouldn't be able to accurately track what objects the client already has in-cache anyhow.

Does any of this seem sensible to people?

The hibernate session on client side means your client application will access the DB using JDBC. You're talking about different netwrok, so it does not seem to be very reasonnable.
Your second proposal, keep synchronized using native OSCache may sounds reasonnable. But if OSCaches keep in touch using JMS, you'll need a JMS queue server on the client side.
I imagine you'll have 10+ clients, it'll be a headache to manage that.
I would have used optimistic locking (version) + a limited time caching on client objects, but no sync.

I'm not all the clear on the details of how JMS works, but I thought that it was set up as Topic/Subscriber. I would figure that the Topic would be handled on a central JMS server (inside JBoss, for example) and that all the clients would subscribe. This would include the 'Master' client inside the application server. I'll have to look further into this.

As far as my first idea, I don't think I'm going to attempt this. The latter idea with OSCache seems like it should work well. If you're correct about each of the clients having to run a full JMS server, though, that will certainly throw a wrench in the works.

Why don't you just write the application the standard way first (session facade at your app server, transfer objects on a need to know/use case basis (following the command pattern another suggested), and then see if it's too slow. If it isn't , then you're golden and haven't had to hack elegance for what may or may not be a faster solution. If it is too slow you have quite a few options: make the clients smarter and then pass enough information for them to work on for a while and send batch updates, or make delegates at the client that contact your session beans and code your own cache at the client (using the local client's session). Good luck.

yeah have a clean design first, then worry about performance. I run into this all the time. Was it Knuth who said, 'Premature optimization is the root of all evil' ? The beauty of Hibernate is that your POJOs aren't too dang large after all.