Last week, did a synchronous delete function, the specific process is, database delete –> call the third party run delete interface, synchronous delete.
The specific process
- After the database has deleted the data, the flag deletion is used here, and then the third-party data is invoked.
- Data needs to be queried through ID before invoking third-party data, but the database is less than data, the SQL statement that allows the console is put in mysql to execute, can check data.
- SQL > alter database mysql > alter database mysql > alter database
The analysis reason
Careful readers should know that the previous data has been deleted, but the latter can not be checked. But there was a lot of business logic back then, and local deletion encapsulated a method. Third party deletions are in a different class. So you don’t take into account that the data is actually deleted, so you can’t find it later.
Transaction isolation level
However, the reason why the data was deleted is still available in mysql, which relates to the isolation level of the transaction. The default isolation level for Spring transactions is based on the database used, in this case mysql, the default isolation level is REPEATABLE_READ.
Since the transaction has not finished executing, other SQL is unable to read the data changes of the transaction. So in SQL execution SQL can find the data.
conclusion
Data read on the database is inconsistent with data read on the code, essentially because the two reads are not under the same transaction, and different transaction isolation levels are used, resulting in inconsistent data read.