# Question about optimistic locking/documentation

**URL:** <https://discourse.hibernate.org/t/question-about-optimistic-locking-documentation/7212>\
**Category:** Hibernate ORM\
**Created:** [February 1, 2023, 9:39am UTC](https://discourse.hibernate.org/t/question-about-optimistic-locking-documentation/7212 "2023-02-01T09:39:26Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![mkomko](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/mkomko/32/2207_2.png) [@mkomko](https://discourse.hibernate.org/u/mkomko)\
**Post date:** [February 1, 2023, 9:39am UTC](https://discourse.hibernate.org/t/question-about-optimistic-locking-documentation/7212/1 "2023-02-01T09:39:26Z")

</div>

The user guide states the following (highlighting added by me):

> A version or timestamp property can never be null for a detached instance. Hibernate detects any instance with a null version or timestamp as transient, regardless of other unsaved-value strategies that you specify. Declaring a **nullable** version or timestamp property is an easy way to avoid problems with transitive reattachment in Hibernate, especially useful if you use assigned identifiers or composite keys.

Shouldn’t this read “non-nullable”?

I’ll give you my scenario:

I want to add optimistic locking to an existing application with an existing database. I added a nullable int column to my tables and an Integer field with the Version annotation to my entities. Since I didn’t update the existing rows, all version columns are NULL.

Now when loading data, I run into the problem that Hibernate detects my instances as transient, as the documentation above states.

So wouldn’t it be better to add a not-nullable int column with the default value 0 to my existing tables and an int property to my entities? Or would it have to be a not-nullable int column in the database with an Integer property in my entities, so Hibernate can properly recognize new entities?

Thank you very much in advance!

---

<div class="post-metadata">

**Author:** ![mkomko](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/mkomko/32/2207_2.png) [@mkomko](https://discourse.hibernate.org/u/mkomko)\
**Post date:** [February 1, 2023, 12:02pm UTC](https://discourse.hibernate.org/t/question-about-optimistic-locking-documentation/7212/2 "2023-02-01T12:02:51Z")

</div>

I also found a Hibernate 6 bug related to Optimistic Locking, Caching and Lazy Loading:  
[https://hibernate.atlassian.net/browse/HHH-16126](https://hibernate.atlassian.net/browse/HHH-16126)

---

<div class="post-metadata">

**Author:** ![beikov](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/beikov/32/258_2.png) [@beikov](https://discourse.hibernate.org/u/beikov)\
**Post date:** [February 1, 2023, 2:43pm UTC](https://discourse.hibernate.org/t/question-about-optimistic-locking-documentation/7212/3 "2023-02-01T14:43:05Z")

</div>

I think that the following part is just a bad choice of words.

> **Declaring a nullable** version or timestamp property is an easy way to avoid problems with transitive reattachment in Hibernate, especially useful if you use assigned identifiers or composite keys.

What this means to say is, that setting the version or timestamp property of an entity instance to `null` is an easy way …

I don’t think that the JIRA issue is related to your question.

---

<div class="post-metadata">

**Author:** ![mkomko](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/mkomko/32/2207_2.png) [@mkomko](https://discourse.hibernate.org/u/mkomko)\
**Post date:** [February 1, 2023, 3:01pm UTC](https://discourse.hibernate.org/t/question-about-optimistic-locking-documentation/7212/4 "2023-02-01T15:01:34Z")

</div>

Thank you very much for your answer.

> What this means to say is, that setting the version or timestamp property of an entity instance to `null` is an easy way …

Okay, that makes more sense.

Would you thus agree that having a non-nullable version column and a nullable Java type in the entity (like Integer) would be the best way to go?

> I don’t think that the JIRA issue is related to your question.

Not directly, no, but I ran into it when trying to implement Optimistic Locking in our application.

Thanks in advance!

---

<div class="post-metadata">

**Author:** ![beikov](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/beikov/32/258_2.png) [@beikov](https://discourse.hibernate.org/u/beikov)\
**Post date:** [February 1, 2023, 3:15pm UTC](https://discourse.hibernate.org/t/question-about-optimistic-locking-documentation/7212/5 "2023-02-01T15:15:26Z")

</div>

> Would you thus agree that having a non-nullable version column and a nullable Java type in the entity (like Integer) would be the best way to go?

Yes