Hello. I've recently taken a new job and have been exposed to Hibernate for the first time. I was hired to write a front-end swing application for data entry and analysis. The other developer has already spent months creating a fully-functional Hibernate-based ORM system that covers the entire database, and when I took the job I was instructed to compile the Hibernate objects into my client application and use them to talk to the database.

Having never used Hibernate, I dove in, figured out how to use it for data access, and got all the objects working flawlessly in short order.

I have proceeded to create a beautiful user interface in Swing. The Hibernate Objects are extremely useful and make coding data access a breeze. I have switched over to using Hibernate for my own web-based applications and found it to be a godsend; with the database on the same machine as the Hibernate objects, it runs faster than tuned SQL does. The problem is that there is no application server; the Hibernate objects are being created on each client independantly.

So the application is being run remotely, at a number of sites in a thousand mile radius, many of them only connected to the network over DSL or 56K modem lines. When run on the local network (with the database in another building but client machines on the same LAN), the application is quite slow, but over a 56K line it can take six minutes to load a simple screen with only small sets of data compared to the eventual thousands of objects that the users will need. When the app starts, all of the objects need to map themselves to the Oracle database thousands of miles away, so users can wait ten to twenty minutes for the Hibernate sessionfactory to initialize.

I realize that most Hibernate implementations do not install Hibernate on every client machine. It seems very strange and wrong-headed to me. If I had a choice I would be putting Hibernate on a central server and use RMI or Web Services to talk to the Hibernate objects. But the group I work for insists that I do it with Hibernate built into the client. I take pride in my work, especially the responsiveness of my interfaces (my last job was writing business apps in C for cell phones). I've written about 30 Java swing applications of different sizes, dozens of servlet-based apps over weblogic and tomcat, PERL cgi's, and have written my own servers in C.

Am I cruisin' for a bruisin' here? I've looked through all the Hibernate documentation and it looks to me like it is intended to run on the server, where it excels in every possible way. Since they have spent tons of time and effort building all of these objects, they don't want me telling them they are useless and will have to be thrown away. By the way, the reason for doing it this way is that the app has to be intermittantly disconnected (used on tablet PC's far away from cell towers). The remote machines will eventually have a different local databse and Hibernate will make switching between the Oracle and HSQLDB dialects a breeze. A seperate synchronizer app will push bulk data between the two, using Hibernate on the client, since there is no app server. At least in theory ...

I don't know what to do. I really like this job but I feel installing Hibernate on every client tablet PC is the wrong decision. I have converted a few screens to just use JDBC and the speed is as expected, so it's not something wrong with the network. Should I:

A) Keep writing the app to use a local version of Hibernate to do data access on the remote server, and hope that once the synchronizer is complete the app will run snappy when disconnected.

B) Cut my losses, quit and find another job, even though I really love working there.

C) Demand that the architecture be restructured to use a thinner protocol, like Web Services talking to Hibernate on an app server (unlikely, there is no app server) or direct JDBC. I'm a master SQL person and if I have to I can easily switch to doing that.

D) Listen to the Hibernate masters, who will find some way to get around all these problems so that a local version of Hibernate can run fast even though the database is only reachable over 56 lines.

Thank you in advance for reading my plea, and please frankly and candidly let me know what you think about the situation.

Dunwitch

It's likely that the slow-down is due to proxying and all that. You could try using hibernate only as a simple ORM, with no relationships that will be proxied. If an object A references a small, simple object B, then eagerly fetch it always; if it references a normal/complex object C, then just have a property returning C's id. Whenever you need the C object, use your DAL's factory methods, which will all issue things like session.load(C.class, a.getCid()). It's a complete waste of hibernate's power, but if the proxying is killing your app, then you'll have to avoid using it.

Thanks, that helps. 90% of the objects are simple lookup tables, but the database has 140 different object types, all of which relate to identical database tables with 2-20 records with only an id and a char[30] string.

If I had designed the database I would've done 1 domain/values table with a type table, but I''m stuck with hundreds of identical tables. One database record relates to 20-40 different (but identical) simple lookup objects, each of which is a seperately defined Hibernate object which is mapped independantly. So when you load a record, it is mapped to subobject1, subobject2, subobject3 ... subobject24, subobject25 etc ... all of which are identical in the database but stored in seperate tables. Each has its own POJO. I need to load 3000 of the base objects to display a screen. With SQL tracing on, I see 10-200 generated SQL queries per record, but all I need is the index for the lookups, really. But whenever I suggest caching the text and just dealing with the indexes I get smacked. The problem is I get a massive angry response whenever I try to suggest modifying the system. I can pull and push the data I actually need in binary and it is less than 1K, but the transfer rates are pushing .3 MB per record because of all the mapped sub-objects (at least for the first few records - Hibernate is very good at reusing already pulled records).

Has anybody implemented a fat-client over a thin wire connection? I want to convince them to use an app server.

***Edit: I should clarify - I don't have any control over the actual Hibernate objects. I just have to use them to access the database from my user interface.***

Hi Dunwitch,

I'm redeveloping an app (3 tier Swing/RMI/Hibernate), but have the luxury of writing my own server side component. I'm just about to launch into the "glue" to cache lookup tables etc.

Did you have any success in your project?

Paul C.

Well, yes and no. I identified the major choke points and hand-coded the SQL just to pull that stuff independently. Since 95% of the screens just use a few objects, these all stay the same. The users still have to suffer through the mapping process however, and over a 56K line that can take a very long time. It still might be a deal-breaker. RMI would be perfect for the connected component. But I'd have to seperately engineer the disconnected/synchronization piece. Good luck on your project and give your app server a hug for me.

Thanks for your reply.

Can't hug the app server - I still have to write it.

Actually, after looking for posts on using Hibernate and Swing, I'm wondering if I can utilise JBoss or Geronimo rather than reinventing the wheel. If I could do this it may also alleviate some effort on the threading model etc and make JAAS etc more accessible.

Any thoughts on this approach?

Paul C.

It's certainly worth researching a little. I hate to code anything that might already exist in a robust form.