StaleObjectStateException 1 transaction 1 create and 1 update on the same entity


#1

Hi guys,

I’m just wondering if it is possible to make a save() with jpa(spring boot) to create an entity then a save to update inside a same transaction ? (we’re speaking about the same entity)

Because personally I got something like “optimistic locking failed; nested exception is org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect)” I’m trying to fix this issue since 2 days but I found nothing over all forums, can you help me please ?

Few logs: https://gist.github.com/tanguc/032147b098c3799b3d833376a02c10a8

Thanks,


#2

From your StackTrace:

at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:532)
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:304)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:98)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)
at com.valeo.foobar.credentialsmanager.controller.CredentialsManagerController$$EnhancerBySpringCGLIB$$4b0a1a07.createCertificateAuthority(<generated>)

It looks like the @Controller invokes the commit via the TransactionAspectSupport.commitTransactionAfterReturning which is very odd. Are you annotating the @Controller with @Transactional?

Also, Spring Boot uses the Open-Session in View Anti-Pattern by default. You might want to disable it.

However, the only way to tell what’s wrong with your application is if you provide a replicating test case. Try building a test repository on GitHub which replicates the issue, and I will investigate it once it’s done.


#3

I’m still getting the same error.

About my initial question, what are limitations when a same entity is created then updated ?

Because in my case in my code I’m doing:

  • CREATION of IPK
  • UPDATE of IPK
  • CREATION of CREDENTIALS

However during the flush the order is not the same:

  • CREATION of IPK
  • CREATION of CREDENTIALS
  • UPDATE of IPK

Can you explain me this behavior please ?

Thanks


#4

About my initial question, what are limitations when a same entity is created then updated ?

I need a code example to understand what do you mean by creating, the modifying an entity. Is it in the same Tx? Is it in the same Persistence Context?

Because in my case in my code I’m doing:

  • CREATION of IPK
  • UPDATE of IPK
  • CREATION of CREDENTIALS

However during the flush the order is not the same:

  • CREATION of IPK
  • CREATION of CREDENTIALS
  • UPDATE of IPK

Can you explain me this behavior please ?

Check out this article for an explanation of the Hibernate flush order.


#5

Hi Vlad,
thanks for your answer

Here are screens:
First:

Second : https://pasteboard.co/HWofGt9.png

What do you mean by Tx ? Transaction ? yes it is in the same transaction
About the persistence context I don’t know, mainly because I’m using SpringBoot stack so it would be set by default for this option.

Thanks,


#6

Try to build a replicating test case that we can investigate. Otherwise, it’s impossible to tell what is causing the issue.