In Relation To

I just pushed a new Hibernate Core maintenance release 3.2.7 for download. It is mostly minor fixes and improvements; check out the specifics in the change log either in Jira or SourceForge.

<queue-voice-of-god>In the beginning there was jdocbook-styles...</queue-voice-of-god>

Quite a few folks have asked about the new Hibernate Core modules introduced with the 3.3 release: what each is for, when to use which, etc. I wanted to take a bit to describe what each of the main modules is for and when/how you would use certain combinations. (These modules also define maven artifacts; all Hibernate Core artifacts use org.hibernate groupId).

Hibernate Core 3.3.1 has just been released with its artifacts published to the JBoss Maven Repository. This release fixed a serious issue with CurrentSessionContext (SessionFactory.getCurrentSession()) when running on IBM WebSphere. It also includes quite a few improvements to the enhanced id generators. For details about all the changes in this release, check out it's changelog

3.3.0.GA got released the other day with an uncaught problem. A public method got removed from some of the events (specifically PreInsertEvent and PreUpdateEvent) which is causing problems with Hibernate Validator and which will probably cause problems for any applications utilizing custom listeners for those events.

Hibernate 3.3.0.GA has been released. A big thanks to everyone who helped us get here.

Moving Hibernate source code to our new Subversion home is done. Both developer and annonymous access have been set up. Currently, web access is only available via the Apache module which is less than ideal. We have been told that either Fisheye or ViewCVS access over the Subversion repsoitory will be setup soon.

A bug report was recently opened in Hibernate's JIRA stating that Hibernate incorrectly handles deadlock scenarios. The basis for the report was an example in the /Pro Hibernate 3/ book (Chapter 9). For those perhaps not familiar with the term deadlock, the basic gist is that two processes each hold resource locks that the other needs to complete processing. While this phenomena is not restricted to databases, in database terms the idea is that the first process (P1) holds a write lock on a given row (R1) while the second process (P2) holds a write lock on another row (R2). Now, to complete its processing P1 needs to acquire a write lock on R2, but cannot do so because P2 already holds its write lock. Conversely, P2 needs to acquire a write lock on R1 in order to complete its processing, but cannot because P1 already holds its write lock. So neither P1 nor P2 can complete its processing because each is indefinitely waiting on the other to release the needed lock, which neither can do until its processing is complete. The two processes are said to be deadlocked in this situation.

As I mentioned in my previous blog about Bulk Operations , both UPDATE and DELETE statements are challenging to handle against single entities contained across multiple tables (not counting associations), which might be the case with: