Действительно ли долго живущие транзакции приемлемы?
Я думаю об использовании транзакций в 2-уровневом WPF (или формы окон) приложения следующим способом:
Мы можем начать новую транзакцию, когда мы открываем новую форму для редактирования данных, редактируем и сохраняем изменения прозрачно в этой транзакции. Затем мы можем нажать кнопку "OK" и фиксировать транзакцию или кнопку "Cancel" и откатывать ее. Если мы хотим открыть другое диалоговое окно с этими данными, мы можем использовать вложенные транзакции.
Вопрос: этот способ использовать приемлемые транзакции или нет? Я знаю, что существует много различных способов реализовать такую логику, но я хотел бы перечислить преимущества и недостатки этого.
5 ответов
Вот несколько проблем, с которыми вы можете столкнуться, если пойдете этим путем
- сброс/закрытие соединения/таймаут (если пользователь идет в туалет)
- конфигурация базы данных (база данных в основном предварительно настроена для многих коротких транзакций, а не для длинных. Например, может понадобиться настроить журнал отказов, который отслеживает, что было сделано во время tx)
- lock lock, даже, возможно, тупики (чем дольше транзакции, тем больше шансы, что один и тот же замок будет получен дважды, возможно, в конфликтном порядке)
Это обескураживающая практика. Вместо этого используйте оптимистическую блокировку . При необходимости считывайте данные, храните копию в памяти. При закрытии диалога попытайтесь синхронизировать изменения с БД. Если в промежутке времени в БД были внесены изменения, действие прерывается. Вероятность неудачи будет зависеть от количества пользователей и т. д. Но на практике это часто бывает допустимо.
.NO, не держите транзакцию открытой в ожидании пользовательского ввода. Это плохая конструкция и приведет к проблемам с блокировкой транзакционных ресурсов (БД).
Вам необходимо пересмотреть свой подход. Почему вы должны держать транзакцию открытой, пока пользователь заполняет форму? Мы используем транзакции для управления параллельностью и блокировки совместно используемых ресурсов. Заполнение формы на самом деле не соответствует требованиям.
Долгоживущие транзакции были темой горячих дискуссий в академических кругах.... 1980-х годов, я бы сказал. Проблема в том, что долгоживущая транзакция почти наверняка создает тупик в пессимистическом исполнении и почти наверняка требует сложного разрешения конфликта в оптимистическом исполнении (для чисел можно обратиться к работе Джима Грея "The Dangers of Replication and a Solution", но вскоре тупиковые ситуации возникают с ростом пятой степени размера транзакции, а вероятность столкновения возрастает с ростом второй степени).
Теперь были различные предложения по этой проблеме, такие как "саги" из Салема и Гарсия-Молины, "вложенные транзакции" и т.д. ( другая работа Джима Грея "Концепция транзакции": Добродетели и ограничения" имеет несколько страниц об этом в конце). Большинство предложений касается модели транзакции, более слабой, чем ACID. Например, "длинные транзакции", возможно, придется выставлять на обозрение промежуточные результаты, что нарушает свойство Isolation. Но ни одно из предложений, так сказать, не принесло в отрасль. В основном потому, что эти приемы не были на самом деле... упрощающими и не были нужны для решения реальных бизнес-задач.
Итак, чтобы ответить на ваш вопрос: нет, долгоживущие транзакции не приветствуются в основных движках БД.
Долгосрочные транзакции серьезно повлияют на вашу способность к масштабированию.
Я бы вообще этого не делал, если бы это было возможно.
Как отмечали другие, не следует держать транзакцию открытой в ожидании пользовательского ввода.
.Я согласен с Mitch n Cheeso, но все же есть еще один способ поставить таймаут на окно, вы можете сообщить часам, что если пользователь не нажмет "OK", то окно будет закрыто автоматически и все будет отменено.
Большинство систем, где транзакции являются критическими, например, процесс "Резервации" в авиакомпании, кино и т.д., операторы должны закрывать транзакции в ограниченное время.
.