Блокировка для обработки параллелизма — хорошая идея? [закрытый]
Вы можете попробовать использовать следующее для python2.7:
sudo apt install python-pip
И если вы хотите установить его на python3:
sudo apt install python3-pip
6 ответов
Если Вы не верите Oracle, нет, нисколько. Поэтому Oracle пошла на многое для предотвращения его.
Проблема состоит в том, что читатели могут заблокировать устройства записи и средства чтения блока устройств записи, и писатель должен ожидать, пока все читатели не закончили со строкой, прежде чем она сможет записать. Это задерживает запись и ее вызывающую сторону. Монопольные блокировки (для записи) сохранены в конец транзакции, в случае, если транзакция должна откатываться - это останавливает другие транзакции, видя новое значение до фиксаций транзакции.
В практике блокировка прекрасна обычно, если нет слишком большого количества конкуренции, то же как ни с каким параллельным программированием. Если существует слишком много конкуренции для строки/страницы/таблицы (не, много серверов баз данных делают блокировку целого DB), она заставит транзакции выполняться в свою очередь, а не одновременно.
Oracle использует управление версиями строки, где вместо того, чтобы блокировать строку для записи этого новая версия строки создается вместо этого. Читатели, которые должны повторить их чтения, помнят, какую версию строки они читают. Однако ошибка произойдет, если читатель, это помнит ее чтения, попытается обновить строку, которая была обновлена другим устройством записи, так как эта транзакция считала ее; это должно остановить потерянные обновления. Для обеспечения можно обновить строку, необходимо сказать, что ВЫБОР является FOR UPDATE; если Вы делаете это, это берет блокировку - только одна транзакция может содержать FOR UPDATE строки за один раз, и должна ожидать конфликтующая транзакция.
И более поздняя Изоляция Снимка поддержки SQL Server 2005 года, которая является их именем управления версиями строки. Снова, необходимо попросить блокировки обновления, если необходимо обновить некоторые данные, Вы просто читаете - в SQL Server, используете С (UPDLOCK).
Дальнейшей проблемой с блокировкой является вероятность мертвых блокировок. Это просто, где две транзакции, каждый содержит блокировку на ресурсе другие потребности или в целом цикл транзакций, содержат блокировки, которые друг друга должны прогрессировать. Сервер базы данных будет обычно обнаруживать эту мертвую блокировку и уничтожать одну из транзакций, откатывая его - затем необходимо повторить операцию. Любая ситуация, где у Вас есть несколько параллельных транзакций, изменяющих те же строки, имеет потенциал для мертвой блокировки. Мертвая блокировка произойдет, если строки будут затронуты в другом порядке; очень трудно осуществить порядок, который будет использовать сервер базы данных (обычно, Вы хотите, чтобы оптимизатор выбрал самый быстрый порядок, который не обязательно будет последователен через различные запросы).
Обычно я предлагал бы то же, когда с поточной обработкой - идут с блокировками, пока Вы не можете доказать, что они вызывают проблему масштабируемости, затем разрабатывают, как сделать самые критические разделы свободными от блокировок.
Блокировка базы данных - в противоположность таблице или блокировке строки - является плохим способом иметь дело с параллелизмом; это исключает параллелизм.
Необходимо сначала определить цель. В случае параллельного запроса хотели бы Вы выигрывать последнего пользователя или первого пользователя. Блокировка базы данных является, конечно, плохим путем. Попытайтесь заблокировать таблицу/строки уже в возможном и ASAP блокировки выпуска.
Я думаю не, потому что это полностью снижается и подает Вашу более сложную заявку. Большинство языков имеет превосходные методы обработки параллелизма, и даже затем лучший способ состоит в том, чтобы написать код, который может обработать параллелизм "исходно".
Для большего количества информации о параллелизме в Java: http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html
Вы означаете обрабатывать параллелизм в своем приложении или решать проблему параллелизма, которую Вы имеете с базой данных. Если первый, это не кажется мне хорошим подходом. Если последний, это может быть Вашим единственным ответом без реинжиниринга Ваши схемы.
Существуют многие разумная альтернатива необходимости кодировать какую-то блокировку DMBS самостоятельно. Следует иметь в виду, что некоторая блокировка действительно всегда происходит (атомарные действия, и т.д.), но ключ - то, что Вы не хотите идти туда, если Вы не имеете к. Вы не хотите обедать с философами, если Вы не имеете к. Транзакции являются одним способом обойти блокировку, но это главным образом для фиксаций. Используя поле, которое отмечает/указывает запись, грязен (Грязная комбинация двоичных разрядов) иначе, просто удостоверьтесь, что Вы делаете так атомарным способом доступа. Язык часто имеет подходящее решение, как ссылается предыдущими сообщениями, однако язык обычно только поддерживает приложение, процесс к процессу, параллелизму уровня, и иногда параллелизм должен быть в базе данных. Я не хотел предполагать, что у Вас есть слой большого приложения, но если Вы делаете существует много уровней абстракции, которые обрабатывают это для Вас. TopLink Oracle свободен и является более устойчивым братом, в спящем режиме, оба из которых помогают Вам управлять своими проблемами параллелизма базы данных посредством абстракции, грязных битов, кэширования и ленивой блокировки. Вы действительно не хотите реализовывать их сами, если Вы не кодируете для школьного или персонального проекта. Поймите проблему, но стойте на плечах гигантов.