People using the Criteria API have either transparently or knowingly
used a ResultTransformer .
A ResultTransformer is a nice and simple interface that allows you to
transform any Criteria result element. E.g. you can make any Criteria
result be returned as a java.util.Map or as a non-entity Bean.
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.
In the past few months I got the impression that something in our explanation of object/relational mapping has gone a little wrong. I'm still not sure that this is the fault of any documentation or presentation slide, it's just something that naturally happened...