Сериализация транзакций libpqxx & amp; последствия
Для моей реализации конкретная запись должна быть сделана навалом и без возможности другого вмешательства.
я был сказал что две конкурирующие транзакции таким образом приведут к тому, что первая заблокирует вторую, а вторая может завершиться или не завершиться после первой.
Пожалуйста, разместите документацию, которая подтверждает это. Кроме того, что именно происходит со второй транзакцией, если первая блокирует? Будет ли это в очереди, сбой или какая-то комбинация?
Если это невозможно подтвердить, следует ли установить уровень изоляции транзакции для этой транзакции SERIALIZABLE? Если да, то как это можно сделать с помощью подготовленных выражений libpqxx?
Если транзакции сериализуются, вторая транзакция будет неудачной или будет поставлена в очередь, пока первая не будет завершена?
Если какой-либо из них потерпит неудачу, как это можно обнаружить с помощью libpqxx?
Решение
Единственный способ окончательно предотвратить эффекты параллелизма — это LOCK TABLE ... IN ACCESS EXCLUSIVE MODE каждую таблицу вы хотите изменить.
Это означает, что вы действительно делаете только одну вещь за раз. Это также приводит к забавным проблемам с блокировками, если вы не всегда приобретаете свои блокировки в одном и том же порядке.
Поэтому обычно вам нужно выяснить, какие именно операции вы хотите выполнить, и как они взаимодействуют. Определите, какие эффекты параллелизма вы можете терпеть, и как предотвратить те, которые вы не можете.
Этот вопрос в его нынешнем виде слишком широк, чтобы на него можно было с пользой ответить.
Варианты включают в себя:
-
Исключительно запирающиеся столы. (Это единственный путь сделать многострочное восстановление без проблем с параллелизмом в PostgreSQL прямо сейчас). Остерегайтесь обновления блокировки и блокировок, связанных с порядком блокировки.
-
надлежащее использование
SERIALIZABLEизоляция — но помните, вы должны иметь возможность вести учет того, что вы сделали во время транзакции, и повторить попытку, если передача прервется. -
Тщательная блокировка на уровне строк —
SELECT ... FOR UPDATE,SELECT ... FOR SHARE, -
«Оптимистическая блокировка» / оптимистичное управление параллелизмом, где это необходимо
-
Написание ваших запросов таким образом, чтобы сделать их более дружественными к параллельной работе. Например, замена циклов чтения-изменения-записи обновлениями на месте.
Другие решения
Других решений пока нет …