If the database guaranteed serializable transactions, the simplest way of coding T1 is to deduct $200 from V1, and then verify that V1 + V2 ≥ 0 still holds, aborting if not.
The only information that must be stored during the transaction is a list of updates made, which can be scanned for conflicts fairly easily before being committed.
Potential inconsistency problems arising from write skew anomalies can be fixed by adding (otherwise unnecessary) updates to the transactions in order to enforce the serializability property.
[4][5][6][7] In the example above, we can materialize the conflict by adding a new table which makes the hidden constraint explicit, mapping each person to their total balance.
Phil would start off with a total balance of $200, and each transaction would attempt to subtract $200 from this, creating a write–write conflict that would prevent the two from succeeding concurrently.
In general, therefore, snapshot isolation puts some of the problem of maintaining non-trivial constraints onto the user, who may not appreciate either the potential pitfalls or the possible solutions.
There are arguments both for and against this decision; what is clear is that users must be aware of the distinction to avoid possible undesired anomalous behavior in their database system logic.
[3] InterBase, later owned by Borland, was acknowledged to provide SI rather than full serializability in version 4,[3] and likely permitted write-skew anomalies since its first release in 1985.
In 2008, Cahill et al. showed that write-skew anomalies could be prevented by detecting and aborting "dangerous" triplets of concurrent transactions.