Why is Hibernate Optimistic Locking Failure Exception thrown when saving a new entity?

org.springframework.orm.ObjectOptimisticLockingFailureException: Object of class [com.payumoney.paymentUtil.model.EntityTDR] with identifier [389853]: optimistic locking failed; nested exception is org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) : [com.payumoney.paymentUtil.model.EntityTDR#389853]

Solution :
In the Entity or Model if we are using version column and if we are not mentioned below annotation then we will get this issue

@Generated(GenerationTime.ALWAYS)

Key points:

1. The relationship between the parent and child is bi-directional one-to-many.
2. We use optimistic locking with the version column being a timestamp created by MySQL either during insert or during update. On the version field we specify Generated(GenerationTime.ALWAYS) to ensure that the version details are obtained from the database automatically (avoid the time precision issue between Java and MySQL)
3. During saving a new entity (id = 0), I can see the logs that the entity is being inserted into the database, I can also see the child entities being inserted in the database (via the Hibernate logs). During this process, I can also see the a select is done to get the version details from the database.
4. Soon after the entities are inserted and the session is being flushed, there is a dirty checking is done on the collection and I see a message in the log that the collection is (). Straight after this, I see an update statement on the parent entity’s table and this is where the problem occurs as the version value used in the update statement is different to what is in the database, the exception is thrown.

How to remove the middle of the commit from git local

Rebase or revert are the options. Rebase will actually remove the commit from the history so it will look like that second commit never existed. This will be a problem if you've pushed the master branch out to any other repos. If you try to push after a rebase in this case, git will give you a reject non fast-forward merges error.

Revert is the correct solution when the branch has been shared with other repos. git revert af5c7bf16 will make a new commit that simply reverses the changes that af5c7bf16 introduced. This way the history is not rewritten, you maintain a clear record of the mistake, and other repos will accept the push.

Here's a good way to erase: git rebase -i <commit head>^ That takes you to the commit just before the one you want to remove. The interactive editor will show you a list of all the commits back to that point. You can pick, squash, etc. In this case remove the line for the commit you want to erase and save the file. Rebase will finish its work.