Dimitry SibiryakovPS: Как я уже сказал? NumbusDB существует. Она многопользовательская и в ней нет дедлоков.
Но как они этого добились, я рассказать не смогу: при попытке вкурить её архитектуру у
меня срывает крышу.

Дай, плиз, ссылку, на основании которой пытаешься вкурить архитектуру...

И давайте контрольно сверимся, что мы понимаем под дедлоком:
я понимаю это как ситуацию, когда два и более
процесса начинают ожидать друг-друга из-за занятых ресурсов, часть которых сами же и не отпускают,
а вы?

mikronvromanovпропущено...

Аналогия не верна..
Какая аналогия? С чем? Я вобще аналогий не приводил. О чём вы?
Мне кажется, вы ломитесь в открытую дверь. Всё что вы говорите - я почти во всём с вами согласен
(за исключением в вашем примере: ресурс после изменения нельза освобождать до завершения транзакции),
и никогда этому не возражал. Я даже привёл наглядный пример, где этот метод не работает. 14500341
Давайте его обсудим.
mikron, мы приводим примеры из жизни или распределенной системы, а коллеги говорят о каком-то ядре СУБД, которому копию ресурса сделать — раз плюнуть. Может это потому, что раздел "проектирование бд"?! Как им объяснить, что даже попытка курьеров сначала обзванивать склады и резервировать товар может привести к дедлоку резервирований: даже в случае, когда курьер отказывается от формирования заказа, если нет части заказа, мы сталкиваемся с ситуацией отказа двум клиентам, хотя одному из них могли собрать заказ...

Dimitry SibiryakovАнатоЛойДай, плиз, ссылку, на основании которой пытаешься вкурить архитектуру...
http://tech.groups.yahoo.com/group/Firebird-Architect/messages

Наверное, неудивительно, если пытаться курить архитектуру NuoDB по сообщениям на форуме Firebird, даже если про нее грузит сам Джим Старки. Может что-то более компактное и систематизированное находил?

vromanovПро курьера
Укрьер должен сначала обзвонить все склады - выяснить наличие товара. Потом, составить свой план. И еще раз обзвонить склады в каком либо фиксированном порядке. Например, по номерам. Другие курьеры поступают также. Если кому-то товара уже хватает, он начинает итерацию сначала.
Задумайся, что делают на самих складах при звонках курьера. На складах резервируют товар при звонке курьера? Если да, то при первом или втором? На одном складе находится только один диспетчер? Если нет, как они резервируют один и тот же товар одновременно для разных курьеров? Как быть, если пока мы оформляли резерв на сотую позицию курьеру К1, второй диспетчер зарезервировал всю 101ую позицию курьеру 2...

АнатоЛойDimitry Sibiryakovпропущено...

http://tech.groups.yahoo.com/group/Firebird-Architect/messages

Наверное, неудивительно, если пытаться курить архитектуру NuoDB по сообщениям на форуме Firebird, даже если про нее грузит сам Джим Старки. Может что-то более компактное и систематизированное находил?
Кстати, нашел вот это . При наброске картинки получается вообще вменяемо. Осталось вкурить, как это избавляет от дедлоков. :)

АнатоЛойАнатоЛойпропущено...

Наверное, неудивительно, если пытаться курить архитектуру NuoDB по сообщениям на форуме Firebird, даже если про нее грузит сам Джим Старки. Может что-то более компактное и систематизированное находил?
Кстати, нашел вот это . При наброске картинки получается вообще вменяемо. Осталось вкурить, как это избавляет от дедлоков. :)
А вот и альтернативная картинка :

АнатоЛойАнатоЛойпропущено...

Кстати, нашел вот это . При наброске картинки получается вообще вменяемо. Осталось вкурить, как это избавляет от дедлоков. :)
А вот и альтернативная картинка :
И еще один документ

Dimitry SibiryakovАнатоЛойЕсли нет, как они резервируют один и тот же товар одновременно для разных
курьеров?
Никак, у них непересекающиеся зоны ответственности. Один диспетчер держит левую половину
склада, второй - правую.

То бишь курьер, звоня на склад, звонит по очереди то одному, то другому диспетчеру. Не многовато ли нужно знать курьеру?

Ну или диспетчеры переключают друг на друга. Тогда куча ожиданий переключений курьером, если список для диспетчеров не поделен в соотвествии с вышеупомянутым "мировым порядком номеклатуры". Или один диспетчер постоянно курит вместо работы - в его части списка не поступают заказы...

vromanovDimitry SibiryakovНикак, у них непересекающиеся зоны ответственности. Один диспетчер держит левую половину
склада, второй - правую.
Ну или у них карточки для товаров. И в один момент времени карточка одного товара доступна только одному диспетчеру.
Да-да, проходили. Даже не развиваю тему, а то вернёмся к копии карточек :).

ViPRosАнатоЛой,

When the Viewer’s Transaction Manager Atom sees the
commit of transaction 355555, it tells transaction 377777,
“Sorry, your update failed.”

ViPRosАнатоЛой,

When the Viewer’s Transaction Manager Atom sees the
commit of transaction 355555, it tells transaction 377777,
“Sorry, your update failed.”
Спасибо, тоже уже вкурил.
Итог: серебряной пули не нашлось. На страницах 15-17 документа "NuoDB® Emergent
Architecture" от 2013 года для не сильно вооружённого глаза написано, как система обнаруживает и устраняет таки возникающие у сессий deadlock'и.
Особенно понравилось "All progress stops, until the two transaction Manager Atoms exchange
information and the deadlock is found ."

Жаль, что посылка Дмитрия о том, что в NimbusDB (теперь уже читай NuoDB) deadlock'ов нет, не подтвердилась... Их "успешно" ищут и устраняет ответственные компоненты системы: "Each of the Transaction Managers checks for a “cycle in the dependency graph”,
or in English, a closed loop in the list of transactions waiting for each other."

А безвинно попавшие в дедлок получают отлуп: "The Viewer’s transaction 377777 gets a deadlock error ",
"The Transaction Manager Atom managing the
transaction with the highest transaction identifier tells
its Transaction Engine to undo the last SQL statement
by that transaction and send it a deadlock error. The
application can choose to continue, commit, or roll back,
but the particular statement it tried cannot succeed
unless the application rolls back the transaction and
retries the whole operation. Well-behaved applications
roll back their transactions after a deadlock error."

По русски: "Дедлоки случаются" и в NuoDB, приложения получают выбор, как же с ними поступать, а "благонравные приложения" откатывают свои транзакции после получения сообщений о случившемся дедлоке с их участием.

Итог: причины возникновения дедлоков были понятны всем участникам и так.
Примеры функциональных требований можно плодить пачками.
Основной шаблон получения таких требований:
п.1) вынести за рамками подконтрольного системе все условия возникновения дедлока;
Для ядра СУБД: сессии, которые плодят транзакции и блокируют записи, как это удобно им.
Для распределённой СУБД: те же беспорядочные транзакции.
Для любой разрабатываемой системы: ограничить её функциональные рамки, чтобы условия возникновения находились за рамками системы.

п.2) вынести за рамки архитектурных или технологических возможностей реализацию известных алгоритмов поиска и устранения дедлока;

п.3) добавить ограничения (производительность, эффективность использования ресурсов, просто здравый смысл :)) , которые будут работать на слабые стороны того или иного алгоритма.

Пример для нашего склада и курьеров: мы пишем программу для курьеров, но никак не управляем складами (ни процессами/организацией, ни IT-системой управления складом). Таким образом условия возникновения дедлока находятся за рамками нашей системы.

ТС, аууууу :).