Поддержка ORM обработки мертвых блокировок
Вы должны быть в состоянии достичь этого, статически связываясь с зависимыми библиотеками в вашей общей библиотеке и делая такую связь частной (т. Е. target_link_libraries(MyLib PRIVATE dependencies...)).
Затем вам нужно будет убедиться, что ни одна из частей какой-либо из зависимых библиотек не будет доступна потребителю вашей общей библиотеки (включая любые заголовки, которые считаются экспозицией). Техника PImpl , вероятно, пригодится вам.
5 ответов
Я не знаю ни о какой специальной поддержке инструмента ORM того, чтобы автоматически повторно выполнить транзакции, которые перестали работать из-за мертвых блокировок. Однако я не думаю, что ORM делает заниматься блокировкой/заведением в тупик проблем очень отличающимся. Во-первых, необходимо проанализировать первопричину для мертвых блокировок, затем перепроектировать транзакции и запросы способом, которые мертвых блокировок избегают или по крайней мере уменьшают. Существует много опций для улучшения, как выбор правильного уровня изоляции для (частей) Ваших транзакций, с помощью подсказок блокировки и т.д. Это зависит намного больше от Вашей системы баз данных затем на Вашем ORM. Конечно, помогает, позволяет ли Ваш ORM Вам использовать хранимые процедуры для некоторой подстроенной команды и т.д.
Если это не помогает избежать мертвых блокировок полностью, или у Вас нет времени, чтобы реализовать и протестировать реальную фиксацию теперь, конечно, Вы могли просто поместить попытку/выгоду вокруг Вашего сохранять/фиксировать/сохранять или безотносительно вызова, проверить перехваченные исключительные ситуации, если они указывают, что неудавшаяся транзакция является "жертвой мертвой блокировки", и затем просто вспомните, сохраняют/фиксируют/сохраняют после нескольких секунд, спя. Ожидание нескольких секунд является хорошей идеей, так как мертвые блокировки часто являются признаком, что существует временный пик транзакций, конкурирующих за те же ресурсы, и повторно выполняющий ту же транзакцию быстро снова и снова, вероятно, сделал бы вещи еще хуже.
По той же причине Вы, вероятно, были бы привычка удостовериться, что Вы только пытаетесь однажды повторно выполнить ту же транзакцию.
В сценарии реального мира мы когда-то реализовали этот вид обходного решения и приблизительно 80% "жертв мертвой блокировки, за которыми" следуют на втором движении. Но я настоятельно рекомендую digg глубже зафиксировать истинную причину для заведения в тупик, потому что эти проблемы обычно увеличиваются экспоненциально с числом пользователей. Надежда, которая помогает.
Мертвые блокировки должны ожидаться, и SQL Server, кажется, оказывается в худшем положении в этой передней стороне, чем другие серверы баз данных. Во-первых, необходимо попытаться минимизировать мертвые блокировки. Попытайтесь использовать SQL Server Profiler для выяснения, почему его случай и что можно делать с этим. Затем, настройте свой ORM для не чтения после создания обновления в той же транзакции, если это возможно. Наконец после выполнения этого если Вы, оказывается, используете Spring и В спящем режиме вместе, можно вставить перехватчик для наблюдения за этой ситуацией. Расширьте MethodInterceptor и поместите его в свой боб Spring под interceptorNames. Когда перехватчик будет выполнен, используйте invocation.proceed () для выполнения транзакции. Поймайте любые исключения и определите неоднократно, Вы хотите повторить.
o/r картопостроитель не может обнаружить это, поскольку мертвая блокировка всегда происходит в DBMS, который мог быть вызван блокировками, установленными другими потоками или другими приложениями даже.
Чтобы быть уверенной, часть кода не создает мертвую блокировку, всегда использует эти правила: - делают выборку вне транзакции. Поэтому первая выборка, затем выполните, обработка затем работают, операторам DML нравится, вставляют, удаляют и обновляют - каждое действие в методе или ряду методов, которые содержат / работа с транзакцией должна использовать то же соединение с базой данных. Это требуется, потому что, например, блокировки записи проигнорированы операторами, выполняемыми по тому же соединению (как то же самое соединение установило блокировки ;)).
Часто, мертвые блокировки происходят, потому что любой код выбирает данные в транзакции, которая заставляет НОВОЕ соединение быть открытым (который должен ожидать блокировок), или использует различные соединения для операторов в транзакции.
У меня был беглый взгляд (несомненно, Вы имеете также), и не мог найти ничего предлагающего, которые в спящем режиме, по крайней мере, предлагает это. Это, вероятно, потому что ORMs рассматривают это за пределами объема проблемы, которую они пытаются решить.
Если у Вас есть проблемы с мертвыми блокировками, конечно, следуют за некоторыми предложениями, отправленными здесь, чтобы попытаться разрешить их. После этого просто необходимо удостовериться, что весь код доступа к базе данных перенесен с чем-то, что может обнаружить мертвую блокировку и повторить транзакцию.
Одна система я продолжил работать, была основана на “командах”, которые затем посвятили себя базе данных, когда нажатый пользователь сохраняет, она работала как это:
While(true)
start a database transaction
Foreach command to process
read data the command need into objects
update the object by calling the command.run method
EndForeach
Save the objects to the database
If not deadlock
commit the database transaction
we are done
Else
abort the database transaction
log deadlock and try again
EndIf
EndWhile
Вы можете делать что-то как с любым ORM; мы использовали в системе доступа к данным дома, поскольку ORM были слишком новыми в то время.
Мы выполняем команды за пределами транзакции, в то время как пользователь взаимодействовал с системой. Затем повторно выполните их как выше (когда Вы используете, сделал "сохранение") справляться с изменениями, которые внесли другие люди. Поскольку у нас уже был хороший идеал строк, которые изменит команда, мы могли даже использовать подсказки блокировки или “выбор для обновления” для вынимания всех блокировок записи, в которых мы нуждались в начале транзакции. (Мы закоротили набор строк, которые будут обновлены для сокращения количества мертвых блокировок еще больше),