Я сначала беспокоился, что это на самом деле сабтайпинг, и в функцию сравнения с типом "comparable -> comparable -> Bool" можно подставить, скажем, число и строку. Оказалось, что всё проще.
С СУБД всё плохо. Клеппманн показывал различные гарантии, которые предоставляют транзакции. Самое сильное — сериализабельность, т.е., такое же поведение, как если бы транзакции действительно шли однопоточным образом. Во многих СУБД по умолчанию идут более слабые гарантии — например, "read committed", при котором гарантируется только то, что транзакция будет читать ТОЛЬКО то, что пишут закоммиченные транзакции (кажется, это, например, умолчальное поведение MySQL). При этом вполне возможен, например, такой вариант: две транзакции, A и B; транзакция A пишет два значения в базу, транзакция B их читает. При такой гарантии может быть, что B прочитает одно значение ДО выполнения транзакции A, а другое — после, и увидит неконсистентное состояние базы.
Клеппманн давал табличку, какие гарантии предоставляют разные СУБД; я не помню, что там было с Oracle, но, кажется, по умолчанию сериализабельность не даёт никто.
One more thing: документация к СУБД может говорить "serializability", но это не значит настоящую сериализабельность. Там полная каша с терминологией.
no subject
Date: 2015-11-06 12:56 pm (UTC)Я сначала беспокоился, что это на самом деле сабтайпинг, и в функцию сравнения с типом "comparable -> comparable -> Bool" можно подставить, скажем, число и строку. Оказалось, что всё проще.
С СУБД всё плохо. Клеппманн показывал различные гарантии, которые предоставляют транзакции. Самое сильное — сериализабельность, т.е., такое же поведение, как если бы транзакции действительно шли однопоточным образом. Во многих СУБД по умолчанию идут более слабые гарантии — например, "read committed", при котором гарантируется только то, что транзакция будет читать ТОЛЬКО то, что пишут закоммиченные транзакции (кажется, это, например, умолчальное поведение MySQL). При этом вполне возможен, например, такой вариант: две транзакции, A и B; транзакция A пишет два значения в базу, транзакция B их читает. При такой гарантии может быть, что B прочитает одно значение ДО выполнения транзакции A, а другое — после, и увидит неконсистентное состояние базы.
Клеппманн давал табличку, какие гарантии предоставляют разные СУБД; я не помню, что там было с Oracle, но, кажется, по умолчанию сериализабельность не даёт никто.
One more thing: документация к СУБД может говорить "serializability", но это не значит настоящую сериализабельность. Там полная каша с терминологией.