Специалисты по транзакциям. Научите. Что у нас всегда в

SQL базе стратегия разрешения конфликтов last writer wins?

Вопрос -то в чём?

Твоя подача проблемы очень сильно упрощена, вряд ли в таком формате обсуждения удастся как-то адекватно ответить тебе.

Есть ли другие способы ? Вот если есть две конкурирующие транзакции за изменение одного рессурса, то как решается данные какой транзакции останутся, а какой нет

Могут решаться по-разному. В том числе это может программно управляться программистом.

а есть ли практики, чтобы база write write conflict разрешала как-то иначе, а не как LWW?

Откатывается last writer, например. А вообще, о чём конкретно вопрос, в самом деле?

Отказаться и чем замерить ? Ведь Локи это же тоже LWW. Вот первая заложила. Вторая ждёт . Первая закомитила. Вторая обновляет и комитет. Вторая - lww.

Не знаю, обычно для этого в большинстве СУБД вообще ничего не надо делать.

Так что вопрос странный...

Мне хочется понять как раз как работает СУБД. Какие у нее есть варианты в этой ситуации

Давай детально приведи ситуацию когда тебе надо разрешить.

Нет. Это не lww

А в чем отличие ? По факту изменения в конечном итоге сохранились от того , кто последним захватил Лок.

Короче вот тебе статья, читай сам. http://citforum.ru/database/classics/SQL_critiques/

По факту тебе надо определить что за LWW. По интуиции, это похоже очень на проблему lost update, которая тоже имеет 2 трактовки.

> Вторая обновляет и комитет. Нет. Вторая откатывается СУБД, как только первая закоммитилась, например. И никакого LWW, нет?

а почему она откатывается? Это когда так изменилась запись, что уже не попадает под условия второго запроса?

Просто потому, что запись была изменена первой транзакцией. Кстати, так работает большинство "версионников" на уровнях изоляции выше RC, насколько я помню.

По разным причинам может

в read commited не будет, если вот скажем у нас такой запро update t1 set f1 = 1, а в другой сессии update t1 set f1 =2;

а как vector clocks работает? что-то я читал и не понял в чем татам идея

Или будет. Т.е. поведение зависит от конкретной СУБД. Хотя именно такого я сходу не помню, если честно. ;)

в CRDT конфликтов вообще нет. их резолвить не нужно