|
Задавайте вопросы, мы ответим
Вы не зашли.
Ситуация - выполняю запрос, в запросе должна произойти вставка определёнонй строки.
Нередко мне вываливается Lock wait timeout. По логике программы я жду минутку, потом пробую ещё раз. И после повторной попытки, вижу что на самом деле, предыдущая попытка добавления записи получилась. Собственно вопрос - можно ли по каким-нибудь признакам определить исполнился ли запрос или нет пусть даже сервер вывалил ошибку?
Конечно, я понимаю, что в таком случае я могу просто сделать запросик, которым и понять, но интересует вариант без дополнительного запроса. Версия Mysql - 5.0.51.
Неактивен
Если используете MyISAM, то такой возможности нет. Если требуется знать точно, то используйте Innodb. В этом случае запрос либо исполнится, либо откатится полностью. В случае ошибки запрос не будет исполнен частично.
Неактивен
Использую InnoDB. И в том-то и дело, что запрос исполняется, я это вижу. Но ошибка, связанная с таймаутом, генерится. Так происходит не всегда, но происходит.
На данный момент для эксперимента поставил insert ignore при повторной попытке, рассчитывая на то, что не будет генериться ошибки дублирования. Но тут возник вопрос - как я понимаю ошибка на сервере всё-равно будет генериться при совпадении значения уникального ключа (ключ не автоинкрементный, guid), но не откатит ли это транзакцию?
Неактивен
Попробуйте сделать BEGIN, затем Ваш запрос. Если запрос с ошибкой - делайте ROLLBACK и начинайте транзакцию заново. Это будет стабильный путь.
Вообще говоря то, что Вы пишете странно. Ошибка при выполнении запроса должна откатывать транзакцию автоматически.
Неактивен
Для меня самого странно. Могу предположить, что причина в компоненатх, которые использую - UniDAC. Но факт остаётся фактом.
Вспомнил ещё про частичные откаты транзакций. Подскажите, пожалуйста, куда глянуть, а то вот ищу и всё никак.
Неактивен
Неактивен
INSERT IGNORE не откатит транзакцию, на то и IGNORE.
Ошибка с таймаутом возникает тогда, когда Вы закрываете (ведь Вы закрываете?)
соединение с сервером после того, как стаймаутились на своей стороне, а сервер
в это время успешно вставил строку. Т.е. грубо говоря последотвательность такая:
1. Вы сказали запрос
2. Вы стаймаутились и начали процесс закрытия соединения
3. Сервер успешно завершил запрос и послал Вам ответ, который, впрочем, Вы не
прочитали потому что (4)
4. Вы закрыли соединение
Транзакции, безусловно, проблему полечат, т.к. чтобы записать данные после (3)
нужно получить COMMIT, который не прийдет из-за (4).
Неактивен
