# "read commited" behaviour in app level transaction

**URL:** https://discourse.hibernate.org/t/read-commited-behaviour-in-app-level-transaction/7533
**Category:** Hibernate ORM
**Created:** [April 20, 2023, 4:01pm UTC](https://discourse.hibernate.org/t/read-commited-behaviour-in-app-level-transaction/7533 "2023-04-20T16:01:54Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![David\_Kubecka](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/david_kubecka/32/2377_2.png) [@David\_Kubecka](https://discourse.hibernate.org/u/David_Kubecka)
#### Post date: [April 20, 2023, 4:01pm UTC](https://discourse.hibernate.org/t/read-commited-behaviour-in-app-level-transaction/7533/1 "2023-04-20T16:01:54Z")

</div>

I have a simple KV store implemented in a DB and I have a following code running inside a (outer) transaction (in my case it’s Spring’s `Transactional` but the concrete way doesn’t seem to matter):

```auto
in_new_txn { kvService.save(KeyValue("key", 1)) }
val res1 = repo.read("key").value

in_new_txn { kvService.save(KeyValue("key", 2)) }
val res2 = repo.read("key").value

```

The `key` is a PK (@Id) of the `KeyValue` entity so one would expect a following “logical” sequence of DB queries:

```auto
BEGIN
BEGIN
select * from kv where key = "key"
insert into kv values ("key", 1)
COMMIT
select * from kv where key = "key"
BEGIN
select * from kv where key = "key"
update kv set value=2 where key="key"
COMMIT
select * from kv where key = "key"
COMMIT

```

Everything happens as expected, except the last select is for some reason ommitted, therefore `res2` is 1 instead of 2.

Is this expected? For me not, i.e. I would expect a similar behaviour akin to the DB “read commited” transaction isolation level. That is the outer transaction sees all changes commited by other transactions meanwhile.

If it is expected how I can achieve the intended behaviour?

---

<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: [April 24, 2023, 5:21am UTC](https://discourse.hibernate.org/t/read-commited-behaviour-in-app-level-transaction/7533/2 "2023-04-24T05:21:49Z")

</div>

Assuming that your last call to `repo.read("key")` accesses the same `EntityManager` as the first one, you will observe that the entity is part of the persistence context, so a subsequent read of the entity will result in returning the same entity from the persistence context again. If you want to refresh the data of your managed entity, you will have to call `EntityManager.refresh`.

---

<div class="post-metadata">

### Author: ![David\_Kubecka](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/david_kubecka/32/2377_2.png) [@David\_Kubecka](https://discourse.hibernate.org/u/David_Kubecka)
#### Post date: [April 24, 2023, 7:25am UTC](https://discourse.hibernate.org/t/read-commited-behaviour-in-app-level-transaction/7533/3 "2023-04-24T07:25:39Z")

</div>

Ok. So it can be said that Hibernate’s “isolation level” is similar to repeatable read?

---

<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: [April 24, 2023, 8:47am UTC](https://discourse.hibernate.org/t/read-commited-behaviour-in-app-level-transaction/7533/4 "2023-04-24T08:47:03Z")

</div>

With respect to managed entities, yes, though the refresh operation allows you to also read committed state.
