Después de muchos meses de trabajo ya se puede descargar Hibernate 3.3 GA, la nueva versión del ORM más utilizado para Java. Entre las novedades más destacadas frente a la versión 3.2 anterior:

• Migración a un sistema de construcción con Maven.
• División del proyecto en varios módulos jar (al estilo de módulos Maven), lo que facilita el ver y administrar las dependencias.
• Rediseño de las SPI para el caché de segundo nivel.
• Integración con JBossCache 2.x como proveedor de caché de segundo nivel.

InfoQ publicó una breve entrevista con Steve Ebersole, uno de los líderes de proyecto de Hibernate, en donde cuenta algunos detalles de esta nueva versión y algo del futuro de Hibernate. A continuación un resumen de la entrevista.

Integración con JBossCache 2.x

El mayor cambio a las SPI (Interfaces de servicio) son sobre la capacidad de crear regiones de caché para propósitos particulares. Básicamente Hibernate necesita regiones de caché para 4 usos distintos: datos de entidades, datos de colecciones, resultados de consultas, timestamps de actualizaciones. El SPI anterior trataba de gestionar estos tipos diferentes de una única forma; esencialmente intentaba manejar el caché de datos de una forma única sin importar las características de los datos que se almacenanban. Sin embargo, en la práctica nos dimos cuenta que muchas veces los integradores de caché debian tener en cuenta estas características diferentes. Por ejemplo, con un caché en cluster tiene más sentido utilizar una invalidación sincrónica para los datos de entidad y colecciones, y un modo local para las regiones de consultas y timestamps de actualizaciones. Este tipo de mezclas no se podía hacer con el SPI de manera prolija. El nuevo SPI hace explícitas todas estas distinciones. Por ejemplo, hay un nuevo método "buildEntityRegion" (para las entidades) o "buildCollectionRegion" (para las colecciones), de manera que el proveedor de caché pueda saber el tipo de datos que administrará la región de caché en cuestión, y así construir y configurar una región apropiada.

La integración con JBossCache 2.x es, por ahora, la única integración de caché que utiliza directamente el nuevo SPI (el resto utiliza un bridge entre el SPI nuevo y el viejo). Por lo tanto hace uso completo de los distintos caché y le permite a los usuarios definir comportamientos diferentes para cada región. Con JBossCache 2.x hay dos mejoras específicas sobre JBossCache 1.x, en términos de beneficios para los usuarios de Hibernate. Primero es el agregado de un proceso "putForExternalRead" (poner para lectura externa). Con JBossCache 1.x podíamos tener problemas de performance e incluso deadlocks cuando leíamos datos de una base de datos y los poníamos en la región de JBossCache. Lo que ocurre es que JBossCache adquiere un lock de escritura en el nodo en cual se intenta poner los datos recién leidos, a pesar de que la semántica del caso uso asegura un lock de lectura. Este lock de escritura entonces podía bloquear a otras transacciones. JBossCache 2.x tiene un nuevo método diseñado específicamente para este caso de uso.

La otra mejora de importancia en JBossCache 2.x desde la perspectiva del uso de Hibernate es el hecho que realiza un mejor trabajo gestionando la invalidación dentro del cluster, especialmente con lockeo optimista. La invalidación es importante para Hibernate ya que es la manera más performante de tener un caché de entidades en cluster.

El futuro de Hibernate

Mientras estaba mirando TopLink/OpenJPA también estaba trabajando en el soporte de BytecodeProvider para Hibernate. Realmente me gustó la idea de usar los agentes de la JVM para instrumentar clases dinámicamente a medida que era cargadas, en vez de necesitar un paso extra al momento de compilación. Todavía no tenemos esto en Hibernate, pero esperamos poder agregarlo para Hibernate 4.0, ya que con esa versión dejaremos el soporte para el JDK 1.4.

Ahora que acabamos de lanzar 3.3.0 GA vamos a estar ocupados por un tiempo solucionando los problemas más importantes que vayan surgiendo en JIRA para la serie 3.3.x.

Ya estamos también trabajando en los planes para 3.4 y 4.0. En general no comentamos los planes futuros, pero dado que el trabajo en la versión 3.4 ya comenzó y el conjunto de características esta prácitamente cerrado puedo comentar un poco más. Se está haciendo mucho foco en mejorar la performance y utilización de recursos al utilizar Hibernate en escenarios de cluster. Otra novedad serán los "perfiles de fetch", los que permiten crear estrategias de fetch de objetos en la metadata, y activar estos perfiles en la Session de forma dinámica en tiempo de ejecución. En definitiva, estas dos características serán las más importantes en Hibernate 3.4.