Нужно ли писать ROLLBACK, если запросы терпят неудачу?

Я думаю, вы спрашиваете, требуется ли выполнение ROLLBACK, так как без него коммиты по-прежнему не применяются. Это технически верно, но только потому, что транзакция по-прежнему открыта, так как вы ее не закончили. Все, что неявно совершает транзакцию (например, запуск новой транзакции), будет действовать так, как будто вы запустили COMMIT, что является противоположностью того, что вы хотите

Причина использования транзакций заключается в объединении нескольких изменений вместе, чтобы все они выполнялись атомарно, иначе, если они не могут, не выполняют никаких из них. Другими словами, если какое-либо изменение выходит из строя, транзакция оставит базу данных в логически несогласованном состоянии.

Пример: дебетуйте одну учетную запись в одном UPDATE и запустите другую учетную запись в отдельном UPDATE. Это денежный перевод. Если дебет завершится успешно, но кредит не удастся, вы должны отменить всю транзакцию, иначе окажется, что деньги исчезли в воздухе.

Таким образом, предполагаемое использование будет состоять в откате транзакции, если произойдет одно из изменений.

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

Решите, какая группа изменений должна быть успешной вместе, и поместите их в одну транзакцию. Любые изменения, которые не относятся к этой группе, должны быть в отдельной транзакции.

Вы должны явно использовать ROLLBACK, чтобы дать понять, что вы делаете с тем, кто должен прочитать ваш код позже, что может быть на самом деле вы 🙂

Кроме того, если вы добавите код, который должен быть выполнен после COMMIT / ROLLBACK, лучше явно вызвать его, чтобы иметь более предсказуемое состояние ваших данных. Если вы полагаетесь на auto-ROLLBACK, этот код может ожидать, что база данных будет находиться в немодифицированном состоянии, пока она по-прежнему остается в транзакции с незастроенной транзакцией.

Это зависит от того, как вы выполняете обработку ошибок в целом. Использование транзакций хорошо, потому что, если ваш код внутри транзакции выдает исключение (которое может ИЛИ НЕ МОЖЕТ быть вызвано тем, что запрос базы данных не удался), обычно ваш обработчик исключений приведет к откату.

Более того, если вы закрыли соединение без фиксации, например, потому что процесс неожиданно завершился, откат произойдет неявно, что обычно хорошо (это повышает надежность, потому что, когда процесс перезагружается, он может попробовать снова)

Теперь, конечно, использование PHP и «старого» mysql API не способствует тому, чтобы получить это право, поскольку оно не поддерживает отчет об ошибках по исключениям.

Однако вы можете обходить это путем регистрации обработчика ошибок PHP, который генерирует исключение при возникновении ошибки, вместо того, чтобы использовать метод «взимать с голода в бедствие» по умолчанию:

 "Captain, we've hit an iceberg "Full steam ahead, put more coal in, we'll get to new york soon... 

Если вы настроили PHP для использования постоянных подключений MySQL, то НЕ откатывать транзакции, если что-то не удается, вызовет проблемы для последующих подключений. Транзакции не прерываются автоматически, когда сценарий прерывает / завершает работу, так как соединение сохраняется в фоновом режиме. Любое последующее повторное использование этого конкретного соединения будет продолжаться, как будто ничего не произошло, и вы окажетесь в середине этой старой транзакции.

Кроме того, если транзакция приобрела какие-либо блокировки, эти блокировки все еще остаются активными до тех пор, пока что-то не приведет к откату или не убьет соединение (которое автоматически откатывается). Вы можете в конечном итоге вызвать лог-замятие для любых других запросов, если они касаются заблокированных таблиц / строк.