StaleObjectStateException with Hibernate in read operation?

Question

I am using Hibernate in a listener of Spring DefaultMessageLisenerContainer.

When I let the listener run with multiple threads, I often encounter this StaleStateException for a read only operation:

Query q = session.createQuery("SELECT k FROM Keyword k WHERE k.name = :name").setParameter("name", keywordName);
List<Keyword> kws = q.list()

The exception is thrown at q.list():

optimistic locking failed; nested exception is org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect)

Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.aurora.common.model.Keyword#7550]
at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1934)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2578)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2478)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2805)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:114)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:267)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:259)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:179)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:64)
at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:1175)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1251)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)

It is really strange as read operation should read a fresh copy from DB rather than check for a version conflict and throw StaleObjectStateException.

The name attribute is not the primary key of Keyword object.

UPDATE: My data access code: I am using Spring's HibernateTransactionManager which support thread-bound Hibernate session. The Hibernate session is retrieved through SessionFactory.getCurrentSession() method.

Each transaction wrap around a invoke of listener by assigning the HibernateTransactionManager to MessageListenerContainer:

<jms:listener-container connection-factory="connectionFactory" concurrency="3-3" prefetch="6" transaction-manager="transactionManager">
        <jms:listener destination="${requests}" response-destination="${replies}" ref="chunkHandler" method="handleChunk" />
    </jms:listener-container>

UPDATE : As in the suggested answer, there might be other operations causing staleObjectStateException. I have tried logging out the Session.isDirty(), for all other operations prior to that. They are all read operation. Interestingly, the session is actually marked as dirty after the keyword select by name operation. The actual code is something like this:

for (String n : keywordNames) {
    Keyword k = keywordDao.getKeywordByName(n);
}

The session is dirty after the first iteration. (KeywordDao.getKeywordByName implmentation is as above). Any idea ? Thanks, Khue.

can you put the full data access code? is your session shared across threads? — Subin Sebastian, Jan 21 '13 at 06:09
Do you have any `@PostRead` code in `Keyword` to update the content of the entity, or is there any special logic in Dao that will update the `Keyword` entity after you retrieved? — Adrian Shum, Jan 21 '13 at 09:09
Yup, my bad. There is a part to update the keyword. I marked your question as correct. I am able to refactor the code and remove unnecessary update, thus reduce the staleobject exception. — Khue Vu, Jan 21 '13 at 09:38

Adrian Shum · Accepted Answer · 2016-09-20T01:28:01.670

14

I believe other answers given are not correct. Accessing row does not exist does not give StaleObjectStateException, and simply query an entity is not going to trigger optimistic lock for that entity too.

Further inspection on the stack trace will give some hints for the cause:

at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102) When you are calling query.list()

at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:1175) Hibernate will determine if auto flush of the session is required. By some reason Hibernate believe auto flush is required. (Probably due to you have previously done update on some Keyword entity in the same session, or other entities... that's something I cannot tell honestly)

at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2805) Then Hibernate will flush all the changes in the session to DB. And, the problem of StaleObjectStateException occurs here, which means Optimistic Concurrency check failure. The optimistic concurrency check failure MAY or MAY NOT relates to Keyword entity (coz it is simply flushing all updated entities in session to DB). However, in your case, it is actually related to Keyword entity ( Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.ncs.singtel.aurora.common.model.Keyword#7550])

Please verify what is the cause for the optimistic concurrency failure. Normally we simply rethrow the optimistic concurrency exception to caller and let caller decide if they want to invoke the function again. However it all depends on your design.

edited Sep 20 '16 at 01:28

answered Jan 21 '13 at 06:27

Adrian Shum

38,812
10
83
131

Thanks for your answer. I am trying to identify the cause to see if I can avoid it. Currently if I do a retry, the run time end up lasting the same even if I have more threads because of large number of retries. – Khue Vu Jan 21 '13 at 07:29
I have tried logging out the session.isDirty() checked between all DB operation before this exception-thrown q.list(). But interestingly, none of the previous operations cause the session to be dirty (They are all read). – Khue Vu Jan 21 '13 at 09:01
1

I will suggest you to make use of `jdbcdslog` and dump out the actual update statement & binded variables. That may give you hints on which entity is causing the problem. – Adrian Shum Jan 21 '13 at 09:06
I marked your question as correct. It pointed me to understanding that query.list() result in a auto flush by hibernate prior to the select statement. I have thought that flush() by default is at manual mode. – Khue Vu Jan 21 '13 at 09:36
well it is indeed manual but Hibernate in some cases will do a flush :) . I think it depends on the class of Entity you are fetching and what's in session – Adrian Shum Jan 22 '13 at 04:43
1

@AdrianShum, StaleObjectException does not exist in Hibernate. StaleStateException and StaleObjectStateException do, they are related(see below), and difference is important. Other than that, great answer. – igor.zh Feb 10 '16 at 20:40

score 1 · Answer 2 · edited Jan 21 '13 at 06:07

1

The stalestateException occurs when we try to access a row that doesn't exist. check your keyword.getName() to see what it returns.

edited Jan 21 '13 at 06:07

NoNaMe

6,020
30
82
110

answered Jan 21 '13 at 05:10

Ramya

107
1
1
12

2

True, StaleStateException happens *also* when (from API doc) "we try delete or update a row that does not exist" But the question was about StaleObjectStateException, not StaleStateException. They are related, though. First, StaleStateException is thrown, then, if "versioned" entity is being updated, it gets caught and then StaleObjectStateException is finally thrown. So your statement is correct, but, strictly speaking, unrelated to the original question. – igor.zh Feb 10 '16 at 20:25

score 0 · Answer 3 · answered Jan 21 '13 at 05:19

0

Some other transactions could be updating Keyword entity at the same time as you read and your read operation could result in Stale objects.

This is optimistic locking. You can consider pessismistic locking , but it will seriously affect the performance.

I would suggest catch StaleObjectStateException and try to read again.

answered Jan 21 '13 at 05:19

Subin Sebastian

10,870
3
37
42

I am not OP, but from my understanding, optimistic concurrency checking occurs when you actually do an update and when flushing that to DB. Simply query will not trigger the optimistic concurrency check. – Adrian Shum Jan 21 '13 at 06:15
@Sublin: thanks for your answer. I don't have problem retry the operation but I want to know why a read op. can returned a StaleObject. I don't share Session object between thread, so the read operation should read the object from DB, which should not lead to any out of date object right ? I will update my answer with the data access code – Khue Vu Jan 21 '13 at 06:17
The stale object is not caused by the read directly. Please refer to my answer to know why a read can indirectly cause optimistic concurrency checking – Adrian Shum Jan 21 '13 at 07:21

StaleObjectStateException with Hibernate in read operation?

3 Answers3