That’s right, the new major rev to Hibernate is ready to download (an alpha of it, at least). Check out the road map and changelog for the release.

All in all, it looks like a reasonabyl exciting release – it fills in many of the gaps in varieties of mapping, and adds some convenience functionality. This is excellent since, when I began using Hibernate, many of these things were dismissed as unnecessary. Sometimes it is recognized as being “for marketing purposes”, which I take to mean that they probably would advise against it, but too many people ask for it to leave the features out. Since the whole ORM thing is often predicated on the developers’ inability to control the database schema, I’m very glad to hear this.

It is also promising that the Hibernate team has demonstrated that they will be actively enhancing and maintaining this software. I’ve seen too many other major projects hit a certain point and then just stagnate. Great work, Hibernate team!

We recently moved from the poor session-per-sql-statement approach to Hibernate to the open session in view approach, complete with thread local handling of the session. (Yes, I know I could use Spring.) We do have some large, legacy import jobs that we have been migrating, and they were opening the session at the beginning, importing 40,000 records, and closing the session. At least we were trying.

As best I can figure it, Hibernate’s session cache isn’t limited in size or objects (at least by default). So the import would start strong, slow down, slow to a crawl, and then pretty much kill the server, requiring a reboot (of RedHat). So by never closing the session, we were causing the session cache to grow to occupy most of the system’s memory.

Since the cache really wasn’t doing us any good, I decided to try closing the session after each record was processed. This changed the performance dramatically. The import went from taking days to run and crashing about 2/3rds of the way through to completing in a couple of hours. While this discovery isn’t earth-shattering, I thought that I’d put this tip out there in case someone else runs into similar problems.

For most tasks, allowing several queries worth of data to accumulate in the session cache is likely harmless and probably helpful, but be aware of its impact on large jobs.

NoClassDefFoundError: java.lang.nmpcJackets

Huh?

That message greeted me as I attempted to start Compuware’s DevPartner J today. So I look at my JDK 1.4 class reference. Not there. Didn’t think it was. Googled it. 2 results – both related to one FAQ from Compuware.

So apparently they wrote a class that’s required for their product, and then called it a java.lang class! Novel idea – call it com.compuware.devpartner..nmpcJackets. That way, users that see this error will realize it’s a problem with the product configuration instead of thinking that something obscure has gone heinously wrong with their JDK. Ridiculous.

Howard Lewis Ship will be presenting on Tapestry tonight at the Atlanta Java Users Group meeting, details here. Wish I could be there – between my wife’s work function that requires spouse, and my birthday being today, I’m not gonna make it.

It looks like Erik Hatcher will be presenting on it at the Atlanta Java Software Symposium, so I can catch up on it there, though I may only attend the first half to attend the session on JSR-175 Metadata or Groovy.

Sometimes, in Hibernate, the need arises to load part of an object sometimes, and all of it the rest of the time. In that vein, the Lightweight Class pattern is detailed, allowing you to map both a lightweight version of a class and a heavier version.

Now you may cite the often mentioned issue of whether there is a significant performance difference between a small projection and a select(*). In this case, understand that we have little, if any control over our database schema. In this case, realize that the table has about 80 columns, and for some queries that may return hundreds of results, we really only need 2-5 of these columns. There is a performance difference in this extreme case.

This was all well and good, until we discovered a major issue that was causing our lightweight class not to work when we had both the lightweight and heavyweight versions mapped in a many-to-one relationship to a parent class. The problem is based on the fact that Hibernate uses the table name (not the object name) for uniqueness, so when we eagerly fetched the summary object, Hibernate attempted to resolve the detail object in its session cache. Because the summary object has been loaded, the cache will hit for the detail object, and Hibernate will attempt to put the summary object into the detail field, causing some CGLIB class cast issues.

There are a couple of solutions to this. One is a hack, but effective enough – change the table name for one of the classes to be of a different case (one upper case, one lower case) – the uniqueness is based on a case-sensitive table name, so the session cache won’t it. Alternately, Gavin recommends extending EntityPersister, overriding getIdentifierSpace(), and specifying <class persister=”MyPersister”/>.

Both will work. My additional tips on getting lightweight class to work are here (to be used with the Hibernate documentation on the pattern). It looks like a change in a future version of Hibernate (possibly 2.1.7, certainly 3.0) will make this a non-issue, with uniqueness based on persistent class instead of table name. In the mean time, I hope this is helpful.