Location: Austin, TX
Occupation: Software Developer
My Links
20. Nov 2013, 20:43 CET, by Steve Ebersole

The Hibernate team is proud to announce the 4.3.0.CR1 release of Hibernate ORM. This is the first release candidate for 4.3 and JPA 2.1 support. For those who maybe are not familiar with our release methodology, this means that in 2-3 weeks this release will essentially be re-tagged as Final unless some critical bugs are reported with it in the meantime.

I will do a full break down of all the new goodies added over the course of 4.3 development in the Final release announcement. Specific development of note done for CR1 include:

  • Support for JPA 2.1 EntityGraphs. This was the biggie holding us back from going to CR. HHH-8285 and friends
  • Integration of the Hibernate JPA Static Metamodel Generator into the ORM project - HHH-8483
  • Starting on break down of the monolithic DocBook-based manuals into smaller Asciidoc-based topical guides (ongoing) - HHH-8606
  • A number of performance fixes including HHH-8709, 8704, 8698, HHH-8682, etal.

The full version info (including change log) can be seen on the version page

Artifacts and release bundles can be found in the normal places.

09. Oct 2013, 21:32 CET, by Steve Ebersole

Version 4.3.0.Beta5 release of the Hibernate ORM project has just been released. This is a step closer towards JPA 2.1 compliance, but also lots of other goodies. JPA 2.1 work of note includes:

  • HHH-8478 - which should complete AttributeConverter support.
  • HHH-8445 - which adds support for REF_CURSOR parameters and should complete StoredProcedureQuery support.
  • HHH-8276 - which was the major prerequisite step for entity graph support. You'll be using that anytime you load entities directly or by to-one association.
  • HHH-8523 - which improves support for parameters and returns using an explicit TemporalType and defined as Calendar

Entity graph support is still not complete, but as mentioned above most of the necessary prerequisite work has been covered now under HHH-8276 and HHH-7841.

Non JPA 2.1 work of note includes:

  • HHH-8476 - which now manages associated many-to-many table rows with bulk deletes (HQL/JPQL)
  • HHH-7689 - which implements better clean up of JDBC batches during failed transactions. The previous behavior led to problems in the way Spring attempts to reuse Sessions after exceptions (which is technically not supported, but this was a good change to make anyway)
  • HHH-8354 - which adds on top of the new bytecode enhancement work to weave in in line dirty checking. In other word, we now have the ability to have entities and embeddables track their own state changes (via enhancement) and for Hibernate to leverage that knowledge during flush. This is still very young, but promises to significantly reduce flush times in many use-cases. We'll have more announcements about all the bytecode enhancement enhancements later.
  • HHH-8520 - ability to use the hibernate.globally_quoted_identifiers with HBM mappings

The full changelog can be found in Jira at Artifacts can be found in the usual places.

Beta6 is scheduled in Jira already following the normal 4 week time box, however be aware that that release is likely to not happen on that particular day; its more likely to be the week before or the week after as I am traveling that particular week. I'll keep Jira up to date as we go along.

Thanks for the support and contributions!

12. Sep 2013, 21:06 CET, by Steve Ebersole

Back to work after summer fun :)

This release has a lot of work, quite a bit in the form of pull requests. Thanks again!

A lot of the focus here has been on JPA 2.1 support. At this point:

  • AttributeConverter support should be complete; just about- there is still one minor issue which will be addressed in the next release
  • StoredProcedureQuery support should be complete; just about - there is still an issue here too which will be addressed in the next release
  • @ConstructorResult support is mostly done, though you currently can only use one ConstructorResult result per query which will be followed up by
  • JPA schema generation support should be fully done at this point.
  • EntityGraph support is still not in place, though support for loading entities using LoadPlans (which is the internal fulfillment of entity graphs) is done and support for collections is under way.
  • Applications using JPA native (native SQL) query support should be aware of a potentially significant change to better align with the JPA spec. Essentially Hibernate will now flush the EntityManager before running the native query (as long as we are within a transaction). Note that this is a full flush, unlike HQL/JPQL or Criteria queries which perform a partial flush. In Hibernate native SQL query support, partial flush is achievable which is available to JPA native queries by unwrapping. For details see

Non-JPA-related changes to highlight include:

The full changelog can be found in Jira at Artifacts can be found in the usual places.

Also, along with this release came a new release (4.0.4.Final) of the hibernate-commons-annotations support library. For the 2 of you out there who care ;)

Anyway, we will now be back at a 4-week timebox. So the next release (Beta5, or CR if we get to that point by then) will be in 4 weeks from now.


29. May 2013, 21:20 CET, by Steve Ebersole

The Hibernate team is pleased to announce today's release of Hibernate 4.3.0.Beta3. Support for entity graphs is still a work in progress, but all other JPA 2.1 features should be fully operational. Specific JPA 2.1 features fully functional as of this release include:

For the full break down of changes, see the changelog.

10. Apr 2013, 17:24 CET, by Steve Ebersole

At flush-time, Hibernate needs to know what entity state has become dirty (changed) so that it knows what data needs to be written to the database and what data does not. Historically Hibernate only defined one means of such dirtiness checking, but has since added multiple additional schemes which seem to be not as well known. The intent for this blog is to start a base for improving the documentation around dirty checking and these various options.

flush-time state comparison strategy

In such a scheme, the loaded state of an entity is kept around as part of the persistence context (Session/EntityManager). This loaded state is the last known state of the entity data as it exists in the database. That happens whenever the entity is loaded or whenever we update the entity from that persistence context. But either way, we have a last, well-known state of the entity in the database as part of this transaction.

This strategy, then, at flush time, performs a deep comparison between that loaded state and the entity's current state. This happens for every entity associated with the persistence context on every flush, which can be a bit of a performance drain in long running persistence contexts and batch processing use-cases. In fact this is why the documentation discusses the importance of evicting as part of batch processing use-cases, but the same thing applies to long running persistence contexts. The best way to mitigate the performance impact of this strategy is to either:

  1. minimize the number of flushes that occur on a given persistence context (always a good idea anyway)
  2. minimize the number of entities that are associated with the persistence context during each flush

Such a strategy falls into a category of dirtiness checking that I call computed. Initially, this was the only strategy supported by Hibernate. However even as far back as 3.0 (which dates back 8-9 years ago!) Hibernate started branching out into tracked dirtiness checking strategies. The most well known general approach to this is using bytecode enhancement.

Tracked approach : bytecode enhancement

Hibernate's first foray into tracked strategies was through bytecode enhancement, which was how most other JPA providers did tracked dirty checking. This is a process whereby your Java Class's bytecode is read and enhanced (changed) to introduce new bytecode level instructions. Hibernate supports this as an Ant task and also through runtime enhancment, although runtime enhancement currently requires a JPA container and container-managed EntityManagerFactory bootstrapping. Basically, Hibernate does not provide a Java agent to perform the enhancement at classload time. We are not against it so much as we just do not have time and no one has contributed such support to-date; though if you are interested... ;)

The enhancement weaves in support for the entity itself keeping track of when its state has changed. At flush time we can then check that flag rather than performing the state comparison computation.

To apply the build-time enhancement using the Ant task, you'd specify the Ant task like:

<target name="instrument" depends="compile">
    <taskdef name="instrument" classname="org.hibernate.tool.instrument.javassist.InstrumentTask">
        <classpath ... >

    <instrument verbose="true">
        <fileset dir="${yourClassesDir}">
            <include name="*.class"/>

which performs the enhancement/instrumentation on your classes as defined by the nested Ant fileset. It is important that the classpath used to define the task contain the Hibernate jar, all its dependencies and your classes.

To use runtime enhancement, simply enable the setting hibernate.ejb.use_class_enhancer to true. Again, this requires that your application be using JPA container-managed EMF bootstrapping.

There are also third party maven plugins support Hibernate bytecode enhancement within a Maven build.

Be aware that work is under way (actually its first steps are already in the 4.2 release) to revamp bytecode enhancement support. See HHH-7667 and HHH-7963 for details.

Tracked approach : delegation

A new feature added in 4.1 allows all dirtiness checking to be delegated to application code. See HHH-3910 and HHH-6998 for complete design discussions. But essentially this feature allows your application to control how dirtiness checking happens. The idea is that your application model classes are monitoring their own dirtiness. Imagine an entity class like:

public class MyEntity {
    private Long id;
    private String name;

    public Long getId() { ... }
    public void setId(Long id) { ... }

    public Long getName() { ... }
    public void setName(String name) {
        if ( ! areEqual(, name ) ) {
            trackChange( "name", );
        } = name;

    private Map<String,?> tracker;

    private void trackChange(String attributeName, Object value) {
        if ( tracker == null ) {
            tracker = new HashMap<String,Object>();
        else if ( tracker.containsKey( attributeName ) {
            // no need to re-put, we want to keep the original value
        tracker.put( attributeName, value );

    public boolean hadDirtyAttributes() {
        return tracker != null && ! tracker.isEmpty();

    public Set<String> getDirtyAttributeNames() {
        return tracker.keySet();

    public void resetDirtiness() {
        if ( tracker != null ) {

Using the org.hibernate.CustomEntityDirtinessStrategy introduced in 4.1 as part of HHH-3910 we can easily tie the entity's intrinsic dirty checking into Hibernate's dirty checking:

public class CustomEntityDirtinessStrategyImpl implements CustomEntityDirtinessStrategy {
    public boolean canDirtyCheck(Object entity, EntityPersister persister, Session session) {
        // we only manage dirty checking for MyEntity instances (for this example; a CustomEntityDirtinessStrategy
        // manage dirty checking for any number of entity types).
        return MyEntity.class.isInstance( entity );

    public boolean isDirty(Object entity, EntityPersister persister, Session session) {
        return ( (MyEntity) entity ).hadDirtyAttributes();

    public void findDirty(Object entity, EntityPersister persister, Session session, DirtyCheckContext dirtyCheckContext) {
        final MyEntity myEntity = (MyEntity) entity;
        final Set<String> dirtyAttributeNames = entity.getDirtyAttributeNames();

                new AttributeChecker() {
                        public boolean isDirty(AttributeInformation attributeInformation) {
                            return dirtyAttributeNames.contains( attributeInformation.getName() );

    public void resetDirty(Object entity, EntityPersister persister, Session session) {
        return ( (MyEntity) entity ).resetDirtiness();

This delegation could even be combined with some custom bytecode enhancement that you apply to your domain model in order to weave in dirtiness tracking. It also fits very nicely with dynamic models (using Map-backed proxies, etc).

There can currently be only one CustomEntityDirtinessStrategy associated with a SessionFactory/EntityManagerFactory. The CustomEntityDirtinessStrategy implementation to use is defined by the hibernate.entity_dirtiness_strategy setting.


Hopefully this gives a more clear picture of the possibilities for managing dirtiness checking in Hibernate. If things are still unclear discuss in comments and I'll try to aggregate all constructive criticisms and suggestions into the docs.

Showing 6 to 10 of 75 blog entries