Undeprecate session.update method

[mbladel]

With Hibernate 6 we deprecated the Session#update and suggest to use merge instead.

While investigating HHH-16111 I noticed some different behavior regarding Optimistic Locking and increase in the Version attribute, with particular regards to updates to the entity's relationships.

The user's case consists basically in a parent entity with a @OneToMany(mappedBy="...") collection of child entities. The example he provided changes the collection of child entityes on a detached parent entity (by either adding/removing or modifying a child) and tries to reattach the state of the parent entity and its relationship. With Hibernate 5, he used to use the Session#update methods which triggered an update of the parent entity regardless of changes to the child entities collection, thus increasing the Version attribute for optimistic locking.

When upgrading to Hibernate 6, the user switched to using the Session#merge - as suggested by the @deprecated javadoc - which actually behaves differently in this particular case: since the parent entity is the inverse side of the relationship, and no changes to the parent entity itself were made, merge does not increase the Version attribute.

It looks like this is in accordance to the JPA spec, which specifies (section 3.4.2. Version Attributes):

The version attribute is updated by the persistence provider runtime when the object is written to the database. All non-relationship fields and properties and all relationships owned by the entity are included in version checks.

And defines the owning-side of a relationship (section 2.10. Entity Relationships) as:

The inverse side of a bidirectional relationship must refer to its owning side by use of the mappedBy element of the OneToOne, OneToMany, or ManyToMany annotation. The mappedBy element designates the property or field in the entity that is the owner of the relationship.
...

In fact, removing mappedBy from the OneToMany association (making the parent entity the owning side) does correctly trigger an increase of the parent's entity Version even when using the merge method.

In conclusion, update has a different behavior compared to merge: it forces an update of the detached entity's state, as opposed to first selecting the current state and only updating if needed, which affects how Optimistic Locking occurs. For this reason maybe we should leave the option of using the Session#update method to users who want to have this type of behavior.

As an additional note, using Session#update with SelectBeforeUpdate mapping - which is also deprecated - the Version increase does not happen because, like when using merge, the Version of the parent is not increased since there was no change to its state. Also, SelectBeforeUpdate is needed for orphanRemoval to work correctly with update, while merge handles it correctly.

[gavinking]

Yeah merge() has very different semantics and so there’s no way to precisely reproduce the behavior of the old update() method.

But we didn’t deprecate it because it’s redundant. We deprecated it because it’s bug-prone and something we simply don’t want people to use anymore in new code. (On the other hand, we’re not actually removing it yet.)

[beikov]

Ok, linking the original discussion for reference, I think we should at least add a some detail to the deprecation note. StatelessSession#update might have the desired semantics if no orphan removal or reattaching (and hence no select before update) is wanted.

[gavinking]

Well the other possibility is to use LockMode.PESSIMISTIC_FORCE_INCREMENT to force a version update.

[yuan2006]

    @Transactional(rollbackFor = Exception.class)
    public <T> void batchUpdate(List<T> entities) {
        Session session = this.entityManager.unwrap(Session.class);
        session.setJdbcBatchSize(batchSize);
        for (T t : entities) {
            session.update(t);
        }
    }

When I saw the Session#update is deprecated, I updated my code to Session#merge. To update 1000 records to database by this code, it costs only 0.4 seconds. But it costs 10 seconds when session.update(t) is replaced by session.merge(t). Session#update performs very bad. So I reverted by code to session.update(t).
I'd just to say, don't deprecate Session#update and don't remove it in the future version.

[yuan2006]

But I can't get a StatelessSession bean by EntityManager bean. How can I get a StatelessSession bean in the Spring application context? The Version is Spring Boot 3.2.3, and the Hibernate is 6.4.4.Final. Thanks.

[gavinking]

Well you don't have an update() operation on EntityManager either so there's no difference there.

I'm afraid I can't help you with your Spring problems, since I'm most definitely not a Spring user.

[gavinking]

Well you don't have an update() operation on EntityManager either so there's no difference there.

Oh, well, fine, you're using unwrap() for that.

So then, unwrap() the SessionFactory from the EntityManagerFactory and create a StatelessSession. Easy.

[yuan2006]

session#update

    public <T> void batchUpdate(List<T> entities) {
        check(entities);
        Session session = this.entityManager.unwrap(Session.class);
        session.setJdbcBatchSize(batchSize);
        for (T t : entities) {
            session.update(t);
        }
    }

batch update 1000 records, costs 0.496 second

but,
statelessSession#update

    public <T> void statelessBatchUpdate(List<T> entities) {
        check(entities);
        SessionFactory sessionFactory = this.entityManager.getEntityManagerFactory().unwrap(SessionFactory.class);
        StatelessSession statelessSession = sessionFactory.openStatelessSession();
        statelessSession.setJdbcBatchSize(batchSize);
        for (T t : entities) {
            statelessSession.update(t);
        }
    }

batch update 1000 records , costs 8.67 seconds.

Could you review the code, and optimize it?

[gavinking]

Could you review the code, and optimize it?

Sure, of course, my rate is €300 per hour, and it might take me a couple of days work, but I'm at your service.

Alternatively, you could be a good citizen of this open source community, and contribute a solution yourself. Might work out cheaper for you.