2013-08-28 2 views
1

Во время процесса регистрации я использую транзакцию, чтобы заключить все операции, связанные с настройкой учетной записи, чтобы в случае проблемы их можно было отбросить.Иммидационная команда во время транзакции MySQL

Последний элемент, который возникает, - это процесс выставления счетов, так что если платеж будет успешным, операция Commit вызывается для завершения создания учетной записи, если, скажем, карта пользователя отклоняется, я откатываю назад.

Тем не менее, мне интересно, как лучше всего записать журнал попыток биллинга в базу данных, если эта операция записи не «закрыта» транзакцией, защищающей другие операции с базой данных. Возможно ли это в MySQL? Таблица журналов, о которой идет речь, не зависит от других. Удержание данных в приложении для записи после операции отката несколько затруднено из-за устаревших библиотек платежей, созданных до того, как мы начали использовать транзакции. Я хотел бы избежать этого, если у MySQL есть решение.

ответ

2

Я бы не использовал транзакции с этой целью. Описанные вами операции, похоже, имеют полное право на существование независимо.

Например, счет-фактура имеет заголовок и одну или несколько строк. Вы используете транзакцию, чтобы убедиться, что вы не храните неполный счет в своей базе данных, потому что это будет ошибка приложения: в бизнес-логике нет никаких обстоятельств, где у вас есть, например, строка без заголовка.

Однако наличие неподтвержденной учетной записи имеет смысл с точки зрения бизнес-логики. Клиент, вероятно, предпочтет получить информацию о ситуации и сможет предоставить другой способ оплаты, а затем начать заново.

Кроме того, использование транзакции для такого длительного процесса требует сохранения открытого соединения с MySQL Server. Если вам когда-либо понадобится реализовать интерфейс HTTP, вам придется переосмыслить всю логику.

Короче говоря, транзакции - это инструмент для защиты от ошибок приложений, а не механизм для реализации бизнес-логики.

Смежные вопросы