Mnesia: Как заблокировать несколько строк одновременно, чтобы я мог писать / читать «согласованный» набор записей
КАК Я ХОТЕЛ, ЧТОБЫ НАЧАТЬ СВОЙ ВОПРОС
Возьмите таблицу с 26 ключами, az и позвольте им иметь целочисленные значения . Создайте процесс, Ой, который делает две вещи снова и снова
- В одной транзакции записывайте случайные значения для a , b и c таким образом, что эти значения всегда суммируются до 10
- В другой транзакции считайте значения для a , b и c и жалуются, если их значения не составляют 10
. Если вы раскрутите хотя бы несколько из этих процессов, вы очень быстро увидите a , b и ] c находятся в состоянии, в котором их значения не суммируются с 10. Я считаю, что нет способа попросить mnesia «заблокировать эти 3 записи перед запуском записи (или чтения)», one может только mnesia блокировать записи по мере их поступления (так сказать), что позволяет набору значений записей нарушать мое ограничение «must sum to 10».
Если я прав, решения этой проблемы включают в себя
- блокировку всей таблицы перед записью (или чтением) набора из 3 записей - я ненавижу блокировать всю таблицу на 3 записи,
- Создайте процесс, который отслеживает, кто какие ключи читает или пишет, и защищает массовые операции от записи или чтения кем-либо еще, пока операция не будет завершена. Конечно, я должен был убедиться, что все процессы использовали это ... дерьмо, я думаю, это означает, что я написал свой собственный AccessMod в качестве четвертого параметра для activity / 4, что кажется нетривиальным упражнением
- Еще кое-что что я недостаточно умен, чтобы понять.
мысли?
Хорошо, я амбициозный новичок в Erlang, извините, если это глупый вопрос, но
я создаю распределенный кеш в памяти для конкретного приложения, и мне нужно иметь возможность для записи наборов пар ключ, значение в одной транзакции, а также для получения наборов значений в одной транзакции. Другими словами, мне нужно 1) Записать 40 пар ключ , значение в кэш и убедиться, что никто другой не сможет прочитать или записать любой из этих 40 ключей во время этой операции записи с несколькими ключами. ; и, 2) Прочитать 40 ключей за одну операцию и вернуть 40 значений, зная, что все 40 значений не изменились с момента начала этой операции чтения до ее завершения.
Единственный способ, которым я могу это сделать, - заблокировать всю таблицу в начале fetch_keylist ([ListOfKeys]) или в начале write_keylist ([KeyValuePairs], но я не хочу этого делать потому что у меня есть несколько процессов, одновременно выполняющих свои собственные операции чтения и записи multi_key, и я не хочу блокировать всю таблицу каждый раз, когда какой-либо процесс должен прочитать / записать относительно небольшое подмножество записей.
Помощь?
Попытка сделать это будьте более ясны: я не думаю, что речь идет только об использовании обычных транзакций
. Я думаю , что задаю более тонкий вопрос, чем этот. Представьте, что у меня есть процесс, который в рамках транзакции повторяется через 10 записей, блокируя их по мере выполнения.Теперь представьте, что этот процесс запускается, но до перехода к третьей записи ДРУГОЙ процесс обновляет третью запись.Это будет нормально для транзакций, потому что первый процесс не заблокировал третью запись (пока), а ДРУГОЙ процесс изменил ее и освободил до того, как до нее добрался первый процесс. Я хочу получить гарантии, что после запуска моего первого процесса ни один другой процесс не сможет коснуться 10 записей, пока с ними не будет завершен первый процесс.
ПРОБЛЕМА РЕШЕНА - Я ИДИОТ ... Думаю ... Спасибо всем за ваших пациентов, особенно Хинек-Пичи-Выходил! Я подготовил свой тестовый код, чтобы показать проблема, и я мог фактически воспроизвести проблему. Затем я упростил код для удобства чтения, и проблема исчезла. Мне не удалось снова воспроизвести проблему. Для меня это одновременно и неловко, и загадочно, поскольку эта проблема у меня была несколько дней. Также mnesia никогда не жаловалось, что я выполнял операции вне транзакции, и у меня нет грязных транзакций где-либо в моем коде,Понятия не имею, как мне удалось внести эту ошибку в свой код!
Я вбил себе в голову понятие Изоляции и не сомневаюсь, что оно существует снова.
Спасибо за образование.
На самом деле, проблема заключалась в использовании try / catch для операций mnesia внутри транзакции. См. здесь для получения дополнительной информации.