Здравствуйте, vdimas, Вы писали:
V>ЧТД.
V>Тебе уже озвучили всё, что требуется — "иерархия блокировок".
V>Эта терминология покрывает любые их имена cобственные.
Терминология не очень важна.
V>Т.е., блокировки не обязательно называть RO, RW или еще как, типа intent, достаточно их пронумеровать, организовав их в иерархию.
Нет, недостаточно.
V>Глубина иерархии зависит от глубины иерархии модели блокируемых ресурсов.
Брр. Я правильно понял, что вы путаете совместимость блокировок и их гранулярность?
Ну, то есть, скажем, какой порядок относительно друг друга в вашей "нумерации" имеют, например, exclusive table lock и shared row lock?

V>Известно как — за счёт неких допущений несогласованности. ))
Это не ответ. Предположим, мы хотим гарантировать serializable. Какие блокировки будем захватывать при выполнении запроса?
Одиночный exclusive database lock не предлагать.

V>И это тоже одна из причин, почему я перидически рассуждаю о слиянии СУБД и сервера приложений.
V>Потому что у сервера приложений есть информация о прикладном характере хранимых данных, а у СУБД — нет.
Хотелось бы больше конкретики — какую именно информацию сервер приложений может применить для выбора стратегии захвата/отпускания блокировок?

V>Очередное ЧТД, мистер учитель. ))
V>Это не уровень блокировок, это уровень изоляции.
Да, конечно, уровень изоляции.

V>Различные уровни изоляции могут обеспечиваться одними и теми же по иерархии блокировками, скажем, за счёт механизма версионности (расширение идеи COW).
Это всё абстрактные рассуждения в вакууме. Когда дело дойдёт до исполнения запроса, придётся принимать какие-то конкретные решения. Тот же механизм версионности сделает обращения на чтение весьма недешёвыми.

V>Да, не все уровни изоляции обеспечивают ACID, только selialized-доступ.
Это сильно зависит от набора действий, выполняемых в транзакции. Иначе бы все приложения, работающие с Read Committed, текли как решето.

V>Т.е., даже не беря во внимание непонимание тобой отличия сущностей механизма блокировок от обеспечиваемых уровней изоляции, твой ответ всё-равно невпопад.
Вас понесло не в ту степь.
Я не спрашивал, какими блокировками или версионностью обеспечить какой-нибудь Repeatable Read.
Вопрос — гораздо более прагматический: как должен быть устроен код захвата/отпускания блокировок так, чтобы он работал.
Вот вы обмолвились про одну interlocked операцию — и мне как раз непонятно, каким это волшебным образом можно ей обойтись, не ограничивая параллелизм операций.

Здравствуйте, vdimas, Вы писали:
V>ЧТД.
V>Тебе уже озвучили всё, что требуется — "иерархия блокировок".
V>Эта терминология покрывает любые их имена cобственные.
Терминология не очень важна.
V>Т.е., блокировки не обязательно называть RO, RW или еще как, типа intent, достаточно их пронумеровать, организовав их в иерархию.
Нет, недостаточно.
V>Глубина иерархии зависит от глубины иерархии модели блокируемых ресурсов.
Брр. Я правильно понял, что вы путаете совместимость блокировок и их гранулярность?
Ну, то есть, скажем, какой порядок относительно друг друга в вашей "нумерации" имеют, например, exclusive table lock и shared row lock?

V>Известно как — за счёт неких допущений несогласованности. ))
Это не ответ. Предположим, мы хотим гарантировать serializable. Какие блокировки будем захватывать при выполнении запроса?
Одиночный exclusive database lock не предлагать.

V>И это тоже одна из причин, почему я перидически рассуждаю о слиянии СУБД и сервера приложений.
V>Потому что у сервера приложений есть информация о прикладном характере хранимых данных, а у СУБД — нет.
Хотелось бы больше конкретики — какую именно информацию сервер приложений может применить для выбора стратегии захвата/отпускания блокировок?

V>Очередное ЧТД, мистер учитель. ))
V>Это не уровень блокировок, это уровень изоляции.
Да, конечно, уровень изоляции.

V>Различные уровни изоляции могут обеспечиваться одними и теми же по иерархии блокировками, скажем, за счёт механизма версионности (расширение идеи COW).
Это всё абстрактные рассуждения в вакууме. Когда дело дойдёт до исполнения запроса, придётся принимать какие-то конкретные решения. Тот же механизм версионности сделает обращения на чтение весьма недешёвыми.

V>Да, не все уровни изоляции обеспечивают ACID, только selialized-доступ.
Это сильно зависит от набора действий, выполняемых в транзакции. Иначе бы все приложения, работающие с Read Committed, текли как решето.

V>Т.е., даже не беря во внимание непонимание тобой отличия сущностей механизма блокировок от обеспечиваемых уровней изоляции, твой ответ всё-равно невпопад.
Вас понесло не в ту степь.
Я не спрашивал, какими блокировками или версионностью обеспечить какой-нибудь Repeatable Read.
Вопрос — гораздо более прагматический: как должен быть устроен код захвата/отпускания блокировок так, чтобы он не замедлял выполнение запроса на порядок (без учёта времени ожидания на блокировке).
Вот вы обмолвились про одну interlocked операцию — и мне как раз непонятно, каким это волшебным образом можно ей обойтись, не ограничивая параллелизм операций.