Исправление eao197, (текущая версия) :
Ну а если серьёзно, то причин, по которым невозможно выполнить ROLLBACK может быть масса.
Для ценителей таких ошибок у Transaction может быть два метода: commit и rollback, выпускающих наружу исключения. И деструктор, который зовет rollback, если не был вызван commit. Только в деструкторе все исключения из rollback-а проглатываются. Т.к. сам факт вызова rollback в деструкторе показывает, что пользователю Transaction эти ошибки не интересны. Он мог вызвать rollback явно, если ему эти ошибки нужны. Либо же деструктор вызван из-за раскрутки стека при наличии другого исключения.
При этом вызов rollback-а — это в прямом смысле слова очистка ресурсов, в первую очередь на стороне СУБД. Если rollback до сервера по какой-то причине не дошел (обрыв связи, скажем), то сервер сам откатит транзакцию по тайм-ауту или при обнаружении этого разрыва на своей стороне. Если rollback до сервера дошел, то какие-то другие ошибки в процессе выполнения rollback-а уже можно игнорировать.
Почему же, по-разному. :-)
Ну хорошо, покажите, как вы в присутствии и кодов ошибок, и исключений перепишете вот такой фрагмент C++ного кода (если вам не нравится проглатывание исключений rollback-а в деструкторе Transaction):
void some_controller::save_state()
{
Transaction trx{ db_connection() };
save_history();
save_current_state();
save_config();
trx.commit();
}
Мораль - это проблемы приложения, куда сохранить отложенную транзакцию
Мораль в том, что для того, чтобы к вашим словам прислушивались, вместо расставления смайликов вы бы что-нибудь серьезное сказали. А то получается, что во время on-line обработки транзакции у вас возникает исключение на Rollback-е и вы замораживаете обработку транзакции на неопределенный срок. И что делать инициатору операции все это время?
Исходная версия eao197, :
Ну а если серьёзно, то причин, по которым невозможно выполнить ROLLBACK может быть масса.
Для ценителей таких ошибок у Transaction может быть два метода: commit и rollback, выпускающих наружу исключения. И деструктор, который зовет rollback, если не был вызван commit. Только в деструкторе все исключения из rollback-а проглатываются. Т.к. сам факт вызова rollback в деструкторе показывает, что пользователю Transaction эти ошибки не интересны. Он мог вызвать rollback явно, если ему эти ошибки нужны. Либо же деструктор вызван из-за раскрутки стека при наличии другого исключения.
При этом вызов rollback-а — это в прямом смысле слова очистка ресурсов, в первую очередь на стороне СУБД. Если rollback до сервера по какой-то причине не дошел (обрыв связи, скажем), то сервер сам откатит транзакцию по тайм-ауту или при обнаружении этого разрыва на своей стороне. Если rollback до сервера дошел, то какие-то другие ошибки в процессе выполнения rollback-а уже можно игнорировать.
Почему же, по-разному. :-)
Ну хорошо, покажите, как вы в присутствии и кодов ошибок, и исключений перепишете вот такой фрагмент C++ного кода (если вам не нравится проглатывание исключений rollback-а в деструкторе Transaction):
void some_controller::save_state()
{
Transaction trx{ db_connection() };
save_history();
save_current_state();
save_config();
trx.commit();
}
Мораль - это проблемы приложения, куда сохранить отложенную транзакцию
Мораль в том, что для того, чтобы к вашим словам прислушивались, вместо расставления смайликов вы бы что-нибудь серьезное сказали. А то получается, что во время on-line обработки транзакции у вас возникает исключение на Rollback-е и вы замораживаете обработку транзакции на неопределенный срок. И что делать инициатору все это время?