You greatly,
Mybatisplus optimistic locking plug-in principle: intercept SQL and add version related: update the set version + 1 where version=oldversion
Affecting the rows can be judged by the optimistic locking abnormal whether,
Now, within the transaction, even if the data in db version has been modified, the current update based on the data within the session has been read, affect the number of rows to 1, still within a transaction how to throw an optimistic locking exception?

CodePudding user response:

Bosses don't dive

CodePudding user response:

Didn't quite understand your problem, your transaction isolation level is what?

CodePudding user response:

refer to the second floor of the hash reply:

didn't quite understand your problem, your transaction isolation level is what?

mysql default repeatable read isolation level

CodePudding user response:

refer to the second floor of the hash reply:

didn't quite understand your problem, your transaction isolation level is what?

transaction A
1. Select the from XXX table where id=1;
Results: the entity: version=100
2. Other matters changed the id=1, version into a 101.
3. The current transaction within A
UpfateOtherEntity ();//other table updated
The entity. The setxxx="XXX";
Int I=mapper. UpdateById (entity);//modified by other affairs, verdion100 has no
The actual SQL: the update table set=XXX XXX, version=101 where id=1 and version=100;
If (I & lt; 1) throw new OptimisticException (" optimistic locking is unusual, expect the transaction rolled back, but I always=1, this exception is thrown out ");
//: actual transaction commit successfully, otherentity modify success, the entity changes fail, do not meet expectations

CodePudding user response:

No transaction when I==0, no problem, have the transaction I==1 (within a transaction, based on repeatable read, version=100 can also be read, there is nothing wrong with I==1, submit to know influence lines of 0), so how to throw OptimisticException within a transaction

CodePudding user response:

When affairs changed the version number is 1, if this transaction not submitted, the other 2 transaction is to modify the blocks, when the transaction is committed, the two transactions are in 1 transaction manipulation, the modified value, by this time 2 transactions must be modified is not successful, modify the article number is 0, the article is not possible to modify the number is 1, then 2 transaction commit time to tell you that change is not successful,
You modify success, certainly is a problem of the code

CodePudding user response:

refer to write diary 7 floor of the Yangtze river water response:

why to use optimistic locking with transaction? Or why use optimistic locking with transaction? Optimistic locking feature is blocking locks, with optimistic locking within the transaction, you guarantee there will not be the version number conflict problem, SAO years

kiss you sure you won't have to transaction with optimistic locking? a submission, b optimistic locking anomalies, how to roll back a?