Red Hat

In Relation To Hibernate ORM

In Relation To Hibernate ORM

The MySQL Dialect refactoring

Posted by    |       |    Tagged as Discussions Hibernate ORM

Starting with Hibernate ORM 5.2.8, MariaDB gets its own Hibernate dialects.

Why?

While working on the new MariaDB Dialects, I realized that the MySQL Dialects would benefit from simplifying the version hierarchy.

Previously, the MySQL Dialects used to looks like that:

MySQL Dialects before refactoring, align=

As you can see, because of the various MySQL storage engines (e.g. MyISAM and InnoDB), the class hierarchy has diverged in multiple branches. Once we integrated Hibernate Spatial, the MySQL Dialects have become even more convoluted.

For this reason, we created the HHH-11473 Jira issue, which is fixed in Hibernate 5.2.9.

How do we stand now?

After refactoring, the MySQL Dialects look as follows:

MySQL Dialects after refactoring, align=

The following Dialects have been deprecated, therefore, they were not added to the class diagram above:

MySQLMyISAMDialect

Use MySQLDialect instead, as well as the hibernate.dialect.storage_engine=myisam Environment Variable or System Property.

MySQLInnoDBDialect

Use MySQLDialect instead, as well as the hibernate.dialect.storage_engine=innodb Environment Variable or System Property.

MySQL5InnoDBDialect

Use MySQL5Dialect instead, as well as the hibernate.dialect.storage_engine=innodb Environment Variable or System Property.

MySQL57InnoDBDialect

Use MySQL57Dialect instead.

MySQL5InnoDBSpatialDialect

Use MySQL5SpatialDialect instead, as well as the hibernate.dialect.storage_engine=innodb Environment Variable or System Property.

MySQL56InnoDBSpatialDialect

Use MySQL56SpatialDialect which defaults to InnoDB by default.

The MySQLStorageEngine abstraction encapsulates the difference between various storage engines, By delegating this responsibility to a new abstraction, the MySQL Dialect hierarchy got a lot simpler.

Traditionally, MySQL used the non-transactional MyISAM storage engine, and this is the default storage engine for all Dialects that are older than MySQL55Dialect. From MySQL55Dialect onwards, the InnoDB storage engine is used by default.

You can always override the default storage engine by providing the hibernate.dialect.storage_engine Environment Variable or System Property. Unlike other Hibernate configuration properties, this one must not be provided via persistence.xml because the Dialect is bootstrapped prior to the configuration management mechanism.

Conclusion

The deprecated Dialects will be available for a while, but they will surely be removed in a future version of Hibernate, so you better use the new ones instead. This refactoring is useful for two reasons. First, supporting MySQL 8.0 requires a single Dialect, not two. Second, it’s easier for our users as well since the choice is much more straightforward now since there is only one Dialect associated to a given MySQL version.

Hibernate Community Newsletter 4/2017

Posted by    |       |    Tagged as Discussions Hibernate ORM

Welcome to the Hibernate community newsletter in which we share blog posts, forum, and StackOverflow questions that are especially relevant to our users.

Looking for your feedback

We are looking for your feedback in about Hibernate bootstrap in cloud environments. Check out this article for more details. If you have any idea or proposal, don’t hesitate to use the comments section below the aforementioned article.

Articles

Sometimes, it’s easy to miss the basic concepts, and relational databases are no different. Check out this article about how does a relational database work.

We released dedicated Dialects for MariaDB, so you don’t have to use the MySQL-specific Dialects when working with MariaDB.

Integration testing is of paramount importance when building an enterprise application. However, many projects rely on in-memory databases (e.g. H2, HSQLDB) for testing, while in production they use Oracle, SQL Server, PostgreSQL or MySQL. In this article, you’ll find how you can run integration tests faster using tmpfs and Docker.

If you’re using JCache through Spring, Hibernate, and Ehcache, this article explains how you can prevent spontaneous cache creation.

Emmanouil Gkatziouras wrote two articles about Hibernate and Hazelcast as a 2nd-level caching provider:

Russ Thomas wrote https://sqljudo.wordpress.com/2014/12/29/what-every-dba-and-swe-should-know-about-ef/[a comprehensive list of ORM Anti-Patterns. Although the article was written for Entity Framework, the tups apply to JPA or Hibernate.

For our Portuguese readers, Rhuan Henrique Rocha da Silva wrote an article about the meaning of mappedBy in JPA and Hibernate.

Thorben Janssen wrote an article about adding Full-Test Search capabilities to a Hibernate application.

Questions and answers

Eighth bug-fix release for ORM 5.2

Posted by    |       |    Tagged as Hibernate ORM Releases

The Eighth bug-fix release for Hibernate ORM 5.2 has just been published. It is tagged at https://github.com/hibernate/hibernate-orm/releases/tag/5.2.8

The complete list of changes can be found here (or here for people without a Hibernate Jira account).

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

The release bundles can be obtained from SourceForge or BinTray.

MariaDB Dialects

Posted by    |       |    Tagged as Discussions Hibernate ORM

Starting with Hibernate ORM 5.2.8, MariaDB gets its own Hibernate dialects.

About MariaDB

MariaDB is a MySQL fork that emerged in 2009 as a drop-in replacement for MySQL. While for a while, MariaDB and MySQL offered similar functionalities, with time, both MariaDB and MySQL have diverged.

For this reason, we created the HHH-11457 issue, which is fixed in the Hibernate ORM 5.2.8.

Dialect variants

For the moment, you can use one of the following two options:

MariaDBDialect

which is the base class for all MariaDB dialects and it works with any MariaDB version

MariaDB53Dialect

which is intended to be used with MariaDB 5.3 or newer versions

In time, we will add new Dialects based on newer capabilities introduced by MariaDB.

Connection properties

While to connect to a MySQL application, the connection properties look as follows:

  • 'db.dialect' : 'org.hibernate.dialect.MySQL57InnoDBDialect',

  • 'jdbc.driver': 'com.mysql.jdbc.Driver',

  • 'jdbc.user' : 'hibernate_orm_test',

  • 'jdbc.pass' : 'hibernate_orm_test',

  • 'jdbc.url' : 'jdbc:mysql://127.0.0.1/hibernate_orm_test'

For MariaDB, the connection properties look like this:

  • 'db.dialect' : 'org.hibernate.dialect.MariaDB53Dialect',

  • 'jdbc.driver': 'org.mariadb.jdbc.Driver',

  • 'jdbc.user' : 'hibernate_orm_test',

  • 'jdbc.pass' : 'hibernate_orm_test',

  • 'jdbc.url' : 'jdbc:mariadb://127.0.0.1/hibernate_orm_test'

While the URL includes the mariadb database identifier, the MariaDB53Dialect supports Time and Timestamp with microsecond precision, just like MySQL57InnoDBDialect.

Conclusion

If you are using MariaDB, it’s best to use the MariaDB-specific Dialects from now on since it’s much easier to match the MariaDB version with its appropriate Hibernate Dialect.

Recently, the team has been discussing improvements around Hibernate (ORM) usage within cloud based apps and microservices. In particular the fundamental assumption that things will break regularly on these platforms and that services should be resilient to failures.

The problem

In microservices or cloud architectures, services are started in different orders (usually beyond your control). It is possible for the app using Hibernate ORM to be started before the database. At the moment, Hibernate ORM does not like that and will explicitly fail (exception) if it can’t connect to the database.

Another related concern is to consider what is happening if the database is stopped for a while after the app running Hibernate ORM has started and resume working shortly after.

Solution 1: Hibernate waits and retries at boot time

Some users have asked us to delay and retry the connection process in case the database is not present at boot time. That would work and solve the bootstrap problem. It would not solve the database gone while running the app but here at least you have your transaction and the error propagation mechanism covering you. Plus at development time, the boot time problem gone would be quite nice already.

I understand that this is probably a quick win to implement this, but better be sure of the problem before adding that feature. It feels to me that Hibernate ORM bootstrap is not the ideal area to fix that problem. But at the end of the day if it helps enough, it would be worth it.

We are exploring that option and considering alternatives and that’s where we need your feedback.

Wait and retry vs platform notification

In this blog post, I mention the wait and retry approach. It can be replaced by a notification from the cloud platform when a service is up / down.

This avoids the regular polling process at the cost of having to rely on various integrations from various cloud platforms.

Solution 1.b: The connection pool waits and retries

It probably would be better if the connection pool Hibernate ORM uses, implements that logic but there are more than one connection pool Hibernate supports. That’s a minor variation on solution 1.

Solution 2: Hibernate boots in non-functioning mode

If Hibernate ORM cannot connect to the datasbase, it continues its bootstrap process. If an EntityManager is asking for a connection while the database is still unavailable, a well defined exception is raised. To not flood the system, a wait and retry system for connection checking would be in place to only try a few times even when lots of EntityManager are requested.

There are some subtle difficulties here on concurrency and on the fact that we use info from the bootstrap connection to configure Hibernate ORM. The most visible option guessed from the connection is the dialect to use. On the other hand, stopping the app boot process while waiting and retrying like solution 1 proposes is probably not without its challenges.

The exception raised by Hibernate ORM upon DB inaccessibility needs to be treated properly by the application (framework) being used. Like a global try catch that moves the application in degraded mode or propagating the execution error to the client (e.g. HTTP error 500). It might even be helpful if Hibernate ORM was exposing the not ready status via an explicit API.

This could be tied to a health check from the cloud platform. The application would report the not ready but trying status via a /health endpoint that the orchestrator would use.

On database connection breaking

There are many reasons for failing to connect to a database:

  1. Host unreachable

  2. DB server denying access temporarily (e.g. load)

  3. Incorrect port setting

  4. Incorrect credentials

  5. And many more

Should the system go into the wait and retry mode for cases 3, 4, 5? Or should it refuse to deploy?

Solution 3: the smart app (framework)

Another solution is for the app to have a smart overall bootstrap logic. It tries to eagerly start but if a Hibernate ORM connection error occurs, only the inbound request framework is started. It will regularly try and boot and in the mean time return HTTP 500 errors or similar.

This requires an app framework that could handle that. It embeds circuit breaker logic in the app and can better react to specific errors. I wonder how common such frameworks are though.

This is in spirit the same solution as solution 2 except it is handled at the higher level of the app (framework) vs Hibernate ORM.

Solution 4: the cloud / MSA platform restart the apps

An arguably better solution would be for the cloud platform to handle these cases and restart apps that fail to deploy in these situations. It likely requires some kind of service dependency management and a bit of smartness from the cloud infra. The infrastructure would upon specific error code thrown at boot time, trigger a wait and retry deployment logic. There is also a risk of a dependency circularity leading to a never starting system.

I guess not all cloud infra offer this and we would need an alternative solution. OpenShift let’s you express dependencies to make sure a given service is started before another. The user would have to declare that dependency of course.

Solution 5: proxy!

Another solution is to put proxies either before the app inbound requests and/or between the app and the database. Proxy is the silver bullet that lots for cloud platforms uses to solve world hunger in the digital universe.

How many proxies and routing logic does it take to serve a "Hello world!" in the cloud?
Who proxies the proxies?

:)

This approach has the advantage of not needing customized apps or libraries. The inconvenience is more intermediary points between your client and the app or data.

If the proxy is before the application, then it needs a health check or a feedback from the boot system to wait and retry the re-deployment of the application on a regular basis. I’m again not certain cloud infrastructures offer all of this infrastructure.

If the proxy is between Hibernate ORM and the database (like HAProxy for MySQL), you’re still facing some timeout exception on the JDBC side. Which means the application will fail to boot. But at least, the proxy could implement the wait and retry logic.

My questions to you

Do you have any input on this subject:

  • what’s your opinion?

  • what’s your experience when deploying cloud apps?

  • any alternative solution you have in mind?

  • any resource you found interesting covering this subject?

  • would you benefit from solution 1?

  • would you benefit from solution 2?

Any feedback to help us think this problem further is what we need :)

Hibernate Community Newsletter 3/2017

Posted by    |       |    Tagged as Discussions Hibernate ORM

Welcome to the Hibernate community newsletter in which we share blog posts, forum, and StackOverflow questions that are especially relevant to our users.

Articles

If you’re using MySQL, then the GenerationType.AUTO identifier strategy is not the best option. Check out this article for more details and a very simple workaround.

Injecting a JPA/Hibernate Entity Managers wit CDI and Weld is extremely easy. Check out this article for more details.

Concurrency Control is a very difficult topic, and relational databases are no different. If you wonder how different database systems prevent Phantom reads or you are curious about how Two-phase Locking and MVCC work, you should definitely read this article.

Arno Huetter wrote a list of tips to improve application performance when you’re using JPA and Hibernate.

If you’re working on a database system which does not allow you to create temporary tables, then rest assured. Hibernate 5.2.8 adds support for non-temporary table bulk-id strategies.

If you want to separate the entity validation logic from the entity data structures, Hibernate Validator is a very attractive solution.

Time to upgrade

This article is about the HHH-11262 JIRA issue which now allows the bulk-id strategies to work even when you cannot create temporary tables.

Class diagram

Considering we have the following entities:

Class diagram, align=

The Person entity is the base class of this entity inheritance model, and is mapped as follows:

@Entity(name = "Person")
@Inheritance(
    strategy = InheritanceType.JOINED
)
public class Person
    implements Serializable {

    @Id
    private Integer id;

    @Id
    private String companyName;

    private String name;

    private boolean employed;

    //Getters and setters omitted for brevity

    @Override
    public boolean equals(Object o) {
        if ( this == o ) {
            return true;
        }
        if ( !( o instanceof Person ) ) {
            return false;
        }
        Person person = (Person) o;
        return Objects.equals(
            getId(),
            person.getId()
        ) &&
        Objects.equals(
            getCompanyName(),
            person.getCompanyName()
        );
    }

    @Override
    public int hashCode() {
        return Objects.hash(
            getId(), getCompanyName()
        );
    }
}

Both the Doctor and Engineer entity classes extend the Person base class:

@Entity(name = "Doctor")
public class Doctor
    extends Person {
}

@Entity(name = "Engineer")
public class Engineer
    extends Person {

    private boolean fellow;

    //Getters and setters omitted for brevity
}

Inheritance tree bulk processing

Now, when you try to execute a bulk entity query:

int updateCount = session.createQuery(
    "delete from Person where employed = :employed" )
.setParameter( "employed", false )
.executeUpdate();

Hibernate executes the following statements:

create temporary table
    HT_Person
(
    id int4 not null,
    companyName varchar(255) not null
)

insert
into
    HT_Person
    select
        p.id as id,
        p.companyName as companyName
    from
        Person p
    where
        p.employed = ?

delete
from
    Engineer
where
    (
        id, companyName
    ) IN (
        select
            id,
            companyName
        from
            HT_Person
    )

delete
from
    Doctor
where
    (
        id, companyName
    ) IN (
        select
            id,
            companyName
        from
            HT_Person
    )

delete
from
    Person
where
    (
        id, companyName
    ) IN (
        select
            id,
            companyName
        from
            HT_Person
    )

HT_Person is a temporary table that Hibernate creates to hold all the entity identifiers that are to be updated or deleted by the bulk id operation. The temporary table can be either global or local, depending on the underlying database capabilities.

What if you cannot create a temporary table?

As the HHH-11262 issue describes, there are use cases when the application developer cannot use temporary tables because the database user lacks this privilege.

In this case, we defined several options which you can choose depending on your database capabilities:

  • InlineIdsInClauseBulkIdStrategy

  • InlineIdsSubSelectValueListBulkIdStrategy

  • InlineIdsOrClauseBulkIdStrategy

  • CteValuesListBulkIdStrategy

InlineIdsInClauseBulkIdStrategy

To use this strategy, you need to configure the following configuration property:

<property name="hibernate.hql.bulk_id_strategy"
          value="org.hibernate.hql.spi.id.inline.InlineIdsInClauseBulkIdStrategy"
/>

Now, when running the previous test case, Hibernate generates the following SQL statements:

select
    p.id as id,
    p.companyName as companyName
from
    Person p
where
    p.employed = ?

delete
from
    Engineer
where
        ( id, companyName )
    in (
        ( 1,'Red Hat USA' ),
        ( 3,'Red Hat USA' ),
        ( 1,'Red Hat Europe' ),
        ( 3,'Red Hat Europe' )
    )

delete
from
    Doctor
where
        ( id, companyName )
    in (
        ( 1,'Red Hat USA' ),
        ( 3,'Red Hat USA' ),
        ( 1,'Red Hat Europe' ),
        ( 3,'Red Hat Europe' )
    )

delete
from
    Person
where
        ( id, companyName )
    in (
        ( 1,'Red Hat USA' ),
        ( 3,'Red Hat USA' ),
        ( 1,'Red Hat Europe' ),
        ( 3,'Red Hat Europe' )
    )

So, the entity identifiers are selected first and used for each particular update or delete statement.

The IN clause row value expression has long been supported by Oracle, PostgreSQL, and nowadays by MySQL 5.7. However, SQL Server 2014 does not support this syntax, so you’ll have to use a different strategy.

InlineIdsSubSelectValueListBulkIdStrategy

To use this strategy, you need to configure the following configuration property:

<property name="hibernate.hql.bulk_id_strategy"
          value="org.hibernate.hql.spi.id.inline.InlineIdsSubSelectValueListBulkIdStrategy"
/>

Now, when running the previous test case, Hibernate generates the following SQL statements:

select
    p.id as id,
    p.companyName as companyName
from
    Person p
where
    p.employed = ?

delete
from
    Engineer
where
    ( id, companyName ) in (
        select
            id,
            companyName
        from (
        values
            ( 1,'Red Hat USA' ),
            ( 3,'Red Hat USA' ),
            ( 1,'Red Hat Europe' ),
            ( 3,'Red Hat Europe' )
        ) as HT
            (id, companyName)
    )

delete
from
    Doctor
where
    ( id, companyName ) in (
         select
            id,
            companyName
        from (
        values
            ( 1,'Red Hat USA' ),
            ( 3,'Red Hat USA' ),
            ( 1,'Red Hat Europe' ),
            ( 3,'Red Hat Europe' )
        ) as HT
            (id, companyName)
    )

delete
from
    Person
where
    ( id, companyName ) in (
        select
            id,
            companyName
        from (
        values
            ( 1,'Red Hat USA' ),
            ( 3,'Red Hat USA' ),
            ( 1,'Red Hat Europe' ),
            ( 3,'Red Hat Europe' )
        ) as HT
            (id, companyName)
    )

The underlying database must support the VALUES list clause, like PostgreSQL or SQL Server 2008. However, this strategy requires the IN-clause row value expression for composite identifiers so you can use this strategy only with PostgreSQL.

InlineIdsOrClauseBulkIdStrategy

To use this strategy, you need to configure the following configuration property:

<property name="hibernate.hql.bulk_id_strategy"
          value="org.hibernate.hql.spi.id.inline.InlineIdsOrClauseBulkIdStrategy"
/>

Now, when running the previous test case, Hibernate generates the following SQL statements:

select
    p.id as id,
    p.companyName as companyName
from
    Person p
where
    p.employed = ?

delete
from
    Engineer
where
    ( id = 1 and companyName = 'Red Hat USA' )
or  ( id = 3 and companyName = 'Red Hat USA' )
or  ( id = 1 and companyName = 'Red Hat Europe' )
or  ( id = 3 and companyName = 'Red Hat Europe' )

delete
from
    Doctor
where
    ( id = 1 and companyName = 'Red Hat USA' )
or  ( id = 3 and companyName = 'Red Hat USA' )
or  ( id = 1 and companyName = 'Red Hat Europe' )
or  ( id = 3 and companyName = 'Red Hat Europe' )

delete
from
    Person
where
    ( id = 1 and companyName = 'Red Hat USA' )
or  ( id = 3 and companyName = 'Red Hat USA' )
or  ( id = 1 and companyName = 'Red Hat Europe' )
or  ( id = 3 and companyName = 'Red Hat Europe' )

This strategy has the advantage of being supported by all the major relational database systems (e.g. Oracle, SQL Server, MySQL, and PostgreSQL).

CteValuesListBulkIdStrategy

To use this strategy, you need to configure the following configuration property:

<property name="hibernate.hql.bulk_id_strategy"
          value="org.hibernate.hql.spi.id.inline.CteValuesListBulkIdStrategy"
/>

Now, when running the previous test case, Hibernate generates the following SQL statements:

select
    p.id as id,
    p.companyName as companyName
from
    Person p
where
    p.employed = ?

with HT_Person (id,companyName ) as (
    select id, companyName
    from (
    values
        (?, ?),
        (?, ?),
        (?, ?),
        (?, ?)
    ) as HT (id, companyName) )
delete
from
    Engineer
where
    ( id, companyName ) in (
        select
            id, companyName
        from
            HT_Person
    )

with HT_Person (id,companyName ) as (
    select id, companyName
    from (
    values
        (?, ?),
        (?, ?),
        (?, ?),
        (?, ?)
    ) as HT (id, companyName) )
delete
from
    Doctor
where
    ( id, companyName ) in (
        select
            id, companyName
        from
            HT_Person
    )


with HT_Person (id,companyName ) as (
    select id, companyName
    from (
    values
        (?, ?),
        (?, ?),
        (?, ?),
        (?, ?)
    ) as HT (id, companyName) )
delete
from
    Person
where
    ( id, companyName ) in (
        select
            id, companyName
        from
            HT_Person
    )

The underlying database must support the CTE (Common Table Expressions) that can be referenced from non-query statements as well, like PostgreSQL since 9.1 or SQL Server since 2005. The underlying database must also support the VALUES list clause, like PostgreSQL or SQL Server 2008.

However, this strategy requires the IN-clause row value expression for composite identifiers, so you can only use this strategy only with PostgreSQL.

Conclusion

If you can use temporary tables, that’s probably the best choice. However, if you are not allowed to create temporary tables, you must pick one of these four strategies that works with your underlying database. Before making your mind, you should benchmark which one works best for your current workload. For instance, CTE are optimization fences in PostgreSQL, so make sure you measure before taking a decision.

If you’re using Oracle or MySQL 5.7, you can choose either InlineIdsOrClauseBulkIdStrategy or InlineIdsInClauseBulkIdStrategy. For older version of MySQL, then you can only use InlineIdsOrClauseBulkIdStrategy.

If you’re using SQL Server, InlineIdsOrClauseBulkIdStrategy is the only option for you.

If you’re using PostgreSQL, then you have the luxury of choosing any of these four strategies.

Hibernate Community Newsletter 2/2017

Posted by    |       |    Tagged as Discussions Hibernate ORM

Welcome to the Hibernate community newsletter in which we share blog posts, forum, and StackOverflow questions that are especially relevant to our users.

Interviews

Don’t miss our Hibernate developer interview with Dmitry Alexandrov.

If you want to share your story about Hibernate, let us know, and we can share it with our huge community of passionate developers.

Articles

I was told about a new blog post which proclaims that Lazy loading is a code smell. Well, in my experience, this is exactly the opposite since I’m a strong believer that EAGER fetching is almost always a bad way of fetching data. After reading Sebastian Malaca’s article, I managed to find a very interesting series of article on mixing JPA and DDD (Domain-driven design).

DDD is a great approach. However, trying to treat a relational database as if it were a document store can be very detrimental to application performance. All in all, JPA entities are not the same as DDD entities. In fact, JPA entities are just the persistent state of the Domain Model.

Orlando L Otero wrote a tutorial about implementing a Multitenant architecture on top of Spring, Hibernate, and PostgreSQL. Related to Multitenancy, I found this Microsoft article from 2006 very relevant to the day.

Choosing the right entity identifier strategy requires some knowledge of the underlying JPA provider. For this reason, if you want portability, check out how you can replace the suboptimal TABLE strategy with SEQUENCE or IDENTITY.

Thorben Janssen wrote a short guide which introduces several JPQL query features. For more on this topic, check out the exhaustive JPQL and HQL chapter in the Hibernate 5 User Guide.

Hibernate entity queries are suitable when you want to modify the fetched entities, and taking advantage of the dirty checking mechanism. However, if you want to take advantage of advanced SQL query capabilities, you need native SQL queries. Check out this article to learn why native SQL queries are a Magic Wand.

Time to upgrade

Hibernate ORM 5.0.12.Final and 5.1.4.Final released

Posted by    |       |    Tagged as Hibernate ORM Releases
These are the last releases in the 5.0/5.1 series. You will need to migrate to 5.2 for future bugfixes.

Hibernate ORM 5.0.12.Final:

Hibernate ORM 5.1.4.Final:

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

Seventh bug-fix release for ORM 5.2

Posted by    |       |    Tagged as Hibernate ORM Releases

The Seventh bug-fix release for Hibernate ORM 5.2 has just been published. It is tagged at https://github.com/hibernate/hibernate-orm/releases/tag/5.2.7

The complete list of changes can be found here (or here for people without a Hibernate Jira account).

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

The release bundles can be obtained from SourceForge or BinTray.

back to top