Serializability and the Lost Update Problem Serializability is the strongest consistency level with regard to the execution of two concurrent transactions T1 and T2. That is, if T1 and T2 independently change the application between consistent states, and a concurrent execution of T1 and T2 is equivalent to a serial execution of T1 and T2, then that concurrent execution results in a consistent state, after committing both transactions.

For example, the following concurrent execution (time advances to the right)

T1: w(a=1)         w(c=4)
T2:     w(a=2)w(b=3)


where W(x=v) sets (i.e., writes) x to the value v, is equivalent to the serial execution T1;T2, thus it is serializable and both transactions are committed.

However, it is clear that T2's write of a causes T1's write of a to be lost, i.e., we have a lost update despite serializability.

That is, serializability ensures consistent states in face of concurrency, though it does not prevent lost updates, which may have serious consequences (for example, imagine that T1 writes the correct delivery address of a VIP customer, and T2 writes the wrong address, T1 and T2 are run concurrently by different operators, who do not notice the mistake).

Is my statement correct about serializability and lost updates?

If it is correct then the table in "Isolation levels, read phenomena, and locks" in this wiki page can only be wrong with regard to serializability and lost updates.

If so, what other stronger consistency level ensures that there are no lost updates?

Thanks
You say:


  serializability ensures consistent states in face of concurrency, though it does not prevent lost updates


This is not true, since by definition the lost update is the phenomenon arising in presence of Write-write conflict, that is when a transaction B overwrites a value written by a transaction A before the commit of A. This operation can lead to a state which cannot arise from any serial execution of A and B.

Consider for instance, in your example, the case in which the transaction T2 is executed one hour after the transaction T1: this could happen in real life, the execution of the two transactions is serial, that is there is no interference between the two transactions, however the update is wrong since someone wrote a bad address. But this means bad data, not data base inconsistency in itself (in other words, you have a database inconsistent with the reality, but this has nothing to do with concurrency and transaction management, that are properties related to the execution of concurrent operations over the database).