Recently looked back, suddenly found a problem:
Said a lot of data are four isolation levels have solved the problem of the first kind of lost updates (rolled back cover), but did not find to look a lot of information under the read uncommitted isolation level, is how to dispose of the rollback covering this problem

In mysql - under the innoDB, for example, read uncommited level will not apply for the lock is read, writing to apply for long locks - exclusive locks, it can solve the rolled back cover?


And such as two transaction concurrency:

T1 start transaction - & gt; T2 start transaction - & gt; T2 update data X and commit - & gt; T1 update data X, then roll back

The concurrent T1 and T2 above can disappear from T2 updated data, this kind of circumstance is reading under the level of uncommitted how may not appear? Can appear? Why so many materials are said four isolation levels are not be "the first kind of lost updates"?

CodePudding user response:

Read uncommited this level means a transaction can be read by another transaction did not commit point data, by your example, T2 read the T1 uncommitted data, T2 after completion, submit the T1 rollback data, resulting in T2 read data is not the actual data, could trigger a logical judgment on the transaction, this phenomenon has a name, dirty data, the individual thinks, update the lost is easy to cause misunderstanding, with dirty data to presentation is more clear,
Other isolation constituency limits the uncommitted data cannot be read, also won't appear dirty data, but there are other problems, such as repeated reading, T1 reading data transaction execution, T2 modified the T1 read data transaction execution and successfully submitted, and T1 may once again read the data found that data has changed, this can lead to inconsistent,

CodePudding user response:

refer to 1st floor master replies:

read uncommited this level means a transaction can be read by another transaction did not commit point data, by your example, T2 read the T1 uncommitted data, T2 after completion, submit the T1 rollback data, resulting in T2 read data is not the actual data, could trigger a logical judgment on the transaction, this phenomenon has a name, dirty data, the individual thinks, update the lost is easy to cause misunderstanding, with dirty data to presentation is more clear,
Other isolation constituency limits the uncommitted data cannot be read, also won't appear dirty data, but there are other problems, such as repeated reading, T1 reading data transaction execution, T2 modified the T1 read data transaction execution and successfully submitted, and T1 may once again read the data found that data has changed, which lead to inconsistent,

Look at the trouble process
T1 start transaction - & gt; T2 start transaction - & gt; T2 update data X and commit - & gt; T1 update data X, then roll back
In did not involve reading, so you answer "lead to the T2 read data is not actual data" where the reading is?

You may first have to find out what is the first kind of lost updates and the second lost updates to answer the question again

CodePudding user response:

Sorry
You this problem associated with the lock, if the T1 for X and exclusive lock first, then the T2 is actually waiting for T1 to finish transaction before execution, is the jam,
If haven't add exclusive lock during the implementation of the T1, T2 for X and exclusive locks, so after the completion of the T1 will be waiting for the T2 to execution, is blocked,
To update the same data object operation, there will always be first, after the last execution is the final result of success,
Isolation level is in the execution of the transaction, data changes impact on the rest of the transaction,