项目在运行时，save or update 数据库时，由于表中存在乐观锁机制。根据版本号判断是否能更新表中的数据。Hibernate乐观锁。
optimistic locking failed; nested exception is org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect)
出现以上异常，由于乐观锁version没有对上，导致操作数据库失败。
解决方法：如果一个请求方法中，包含两次以上操作该对象表，那么在前面每次操作完数据库之后，需要将操作后的对象返回，然后下次操作时，保证该对象的版本号是最新的。
原因：就是要修改的实体的version和数据库中的version对不上。
hibernate
就会认为别人已经并发修改了数据。
解决
办法：将数据库中的version从前端回传回来。如果version和数据库一致，还是经常出现这个问题，可以考虑使用悲观锁。
乐观锁
：给数据加一个版本， 每一操作数据就更新版本，不会上锁，但是在更新的时候你会判断这期间有没有人去更新这个数据
悲观锁：给数据加了一把锁 ，同事务只能一个线程进行操作，使用完了锁释放， 没释放前后面想要操作的人就得排队 ，效率低，但是很安全
2 问题描述
异常
信息
什么是
乐观锁
乐观锁
(
Optimistic
Lock ) 相对悲观锁而言，
乐观锁
假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。
应用场景：为什么需要
乐观锁
？
在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是著名的并发性问题。
典型的冲突有：
We are
optimistic
that the data will not bechanged by some other user; hence ,we wait until the very last moment to findout if we are right.
There are many methods of implmenting
optimistic
concurr
2. 请求中指定了id， 和version 但是数据库中有这条记录，但是version不正确（和数据库不一致）4. 请求中不指定了id， 和version ，数据库中会新增一条记录，并且version是0。4. service中直接保存：直接调用Spring的 saveAndFlush
方法
保存数据。2. 请求中指定了id， 和version 但是数据库中有这条记录，结果会更新。1. 保存数据 Id 在数据库中是自增长的。
由于使用了mybatis
乐观锁
拦截器,在update时获取version，更新后版本号加1。如果version为null,,就报报
异常
Optimistic
Locking
Exception
："未找到对应的
乐观锁
版本数据，无法完成数据更新。"
一、问题描述
新开发的系统，往往可能需要将旧版的系统中的历史数据，用脚本的方式在新系统中跑一遍业务流程，其实可能是用
Java
代码自动调用一些业务流程接口。
在执行过程中发现
报错
：
2021-01-27 19:32:46.300 [http-nio-5090-exec-4] ERROR o.a.c.c.C.[.[.[.[dispatcherServlet]:182 - Servlet.service() for servlet [dispatcherServlet] in context with path
代码如下:
MyLog myLog = mongoTemplate.find(new Query(Criteria.where("code").is("1234")))
myLog.setRequestDate(new Date());
mongoTemplate.save(myLog);
详细
报错
如下:
exception
ERROR
org
.spri...
