Optimistic locking is not operating lock, but the default is locked? Optimistic locking is how to achieve that??
Can set the mysql to update this statement is not locked??

CodePudding user response:

Optimistic locking is to achieve in the program code

The table with a timestamp column
First select id and the timestamp and then come out with id and the timestamp to update the row
If failed to update the timestamp change, had been changed

CodePudding user response:

I confused the transaction and the definition of the lock before
In mysql, for example: set in the optimistic locking is submitted automatically, which is a statement is a transaction, the transaction level may be submitted also can be read or uncommitted,
Basic steps are:
1. Query the commodity information
Select (status, the status, version) from t_goods where id=# {id}
2. According to the commodity information to generate the order
3. Modify the commodity status of 2
The update t_goods
Set the status=2, version=version + 1
Where id=# # {id} and version={version};
Optimistic locking, each of the above statement is a small transaction, the select can be read casually, only when the update check,
Don't know if I understand this???? Want to correct,,,

CodePudding user response:

reference 1st floor rucypli response:

optimistic locking is to achieve in the program code

The table with a timestamp column
First select id and the timestamp and then come out with id and the timestamp to update the row
If failed to update the timestamp change, had been change

I know, you say you no understand my confusion, but I seem to think now, could you help me see if I understand 2 floor, main is submitted automatically, each statement is a transaction,
thank you

CodePudding user response:

I know you are confused, I also have the same confusion with you, do you understand me, now,

CodePudding user response:

reference 4 floor a675697174 response:

I know you are confused, I also have the same confusion with you, do you understand me, now,

Actually this confusion is two things, mysql to lock, the update statement is to ensure the atomicity of statement level.
The optimistic locking is another matter, for example:
There is a table, a field quantity, bought the goods, the goods list number minus 1, increase inventories will add the number 1.
So there is A scene: A merchants (A), B (A consumer)
A into the ten pieces of goods, the count count + 10=
B bought 5 items, the count=count - 5.
When these two things when it comes to a transactional count how guarantee??
The optimistic locking is realized in the update, judge next version, version is wrong, I read it again, the count will eventually be consistent.

CodePudding user response:

Uh huh, is like this

CodePudding user response:

reference 5 floor super super boy reply:

Quote: refer to 4th floor a675697174 response:

I know you are confused, I also have the same confusion with you, do you understand me, now,

Actually this confusion is two things, mysql to lock, the update statement is to ensure the atomicity of statement level.
The optimistic locking is another matter, for example:
There is a table, a field quantity, bought the goods, the goods list number minus 1, increase inventories will add the number 1.
So there is A scene: A merchants (A), B (A consumer)
A into the ten pieces of goods, the count count + 10=
B bought 5 items, the count=count - 5.
When these two things when it comes to a transactional count how guarantee??
The optimistic locking is realized in the update, determine the version, the version is wrong, I read it again, the count would eventually consistent.

Said is very right, lu Lord answered my doubt

CodePudding user response:

Actually such understanding is flawed, mysql is, indeed, have to a single update statement the default lock, but only a single update,
Such as the UPDATE table1 SET num=num + 1 WHERE id=1; This update statement, in fact, interior is divided into two sentences, to query the value lines of num id=1, again to num value is updated, a=SELECT * FROM table1 WHERE id=1; The UPDATE table1 SET num=a.n um + 1 WHERE id=1; Obviously, to the operation of the num update in a single atomic lock, but not to the operation of the id of 1 lock, so will lead to a problem, the id=1 after the query, get old num value, then another transaction will update and submit the num, we update the num, again will lead to the update of cover, so if you don't want to happen this situation requires the previous id=1 and Shared or exclusive lock locks,
Also is to use optimistic locking, use the update t_goods set status=2, version=version + 1 where id=# # {id} and version={version}; When the update will go to the current version value, if the update will be inconsistent, a=a select * from t_goods where id=# # {id} and version={version} update t_goods set status=2, version=Dr. Ersion + 1 where id=# # {id} and version={version}; If the way be changed, the second version of update statement to modify, cannot update, the first query is just a query to the corresponding value of the version used to update on the second modification statements,,
Learning, I also hope that I said clearly enough, so is its locked and optimism that concurrent update in one of two ways