3 ms·
Transaction isolation is not what you think it is. Most databases run at a liberal isolation level. For example, from the PostgreSQL docs[1] you can read that t
by stingraycharles 13y ago
Transaction isolation is not what you think it is. Most databases run at a liberal isolation level. For example, from the PostgreSQL docs[1] you can read that they use 'read committed' as an isolation level by default. In this example, it could mean that the following could happen:
* At T=1, transaction 1 will read the current balance
* At T=2, transaction 2 will read the current balance
* At T=3, transaction 1 will update the current balance
* At T=4, transaction 2 is in a race condition situation, since the update of transaction 1 'leaks' into transaction 2, but the last read balance in transaction 2 still is the 'old' balance.
In other words: this is an area where a lot of people introduce race condition bugs without being aware of it.
[1] http://www.postgresql.org/docs/9.1/static/transaction-iso.html http://www.postgresql.org/docs/9.1/static/transaction-iso.ht...
- raverbashing 13y agoWhat looks like is needed is a serialization of user transactions. And also risk-avoiding schemas (in the general provisions of the business, not only on the system running it)
- sergiosgc 13y agoThat's the default, but you can, and should, use a serializable transaction isolation level where required by the problem domain.
- stingraycharles 13y agoOf course you should, the problem isn't that it isn't possible to serialize a transaction, the problem is that the default is optimistic. I can only imagine that there will be quite a hefty performance impact if serialized transactions were the default, so I understand their reasoning.