Допустим ситуацию, когда клиент посылает запрос на сервер RDBMS, а потом по таймауту закрывает соединение.
Допустим также, что используется опция autocommit.
Есть ли какие-либо гарантии, что RDBMS сделает rollback?
Здравствуйте, Шубин Евгений, Вы писали:
ШЕ>Допустим ситуацию, когда клиент посылает запрос на сервер RDBMS, а потом по таймауту закрывает соединение. ШЕ>Допустим также, что используется опция autocommit. ШЕ>Есть ли какие-либо гарантии, что RDBMS сделает rollback?
Это от СУБД зависит. У FireBirda раньше транзакции при этом зависали.
Здравствуйте, Шубин Евгений, Вы писали:
ШЕ> Допустим ситуацию, когда клиент посылает запрос на сервер RDBMS, а потом по таймауту закрывает соединение. ШЕ> Допустим также, что используется опция autocommit. ШЕ> Есть ли какие-либо гарантии, что RDBMS сделает rollback?
Не знаю ни одной такой DBMS. Единственное, что гарантируется, это атомарность.
Я даже думаю, что реализовать такую гарантию невозможно, так как пакет, закрывающий соединение, может прийти после того, как commit уже выполнен.
Если нужна такая гарантия, не используй autocommit.
Здравствуйте, wildwind, Вы писали:
W>Не знаю ни одной такой DBMS. Единственное, что гарантируется, это атомарность.
Так это атомарность на стороне сервера? Клиент в неопределенном состоянии по крайней мере пока не прочитал запись, которую пытался записать, что не всегда возможно.
W>Если нужна такая гарантия, не используй autocommit.
Тут же суть не меняется, явный commit тоже может вызвать таймаут.
Здравствуйте, Шубин Евгений, Вы писали:
ШЕ> Так это атомарность на стороне сервера? Клиент в неопределенном состоянии по крайней мере пока не прочитал запись, которую пытался записать, что не всегда возможно.
Это атомарность транзакции. Остальное я что-то не понял.
ШЕ> W>Если нужна такая гарантия, не используй autocommit. ШЕ> Тут же суть не меняется, явный commit тоже может вызвать таймаут.
Правильнее сказать не "commit может вызвать таймаут", а "таймаут может случиться во время вызова commit", по причинам не связанным с СУБД. Такое конечно возможно, но вероятность этого на порядки ниже, чем задержка при выполнении какой-то полезной работы.
Здравствуйте, Шубин Евгений, Вы писали:
ШЕ>Допустим ситуацию, когда клиент посылает запрос на сервер RDBMS, а потом по таймауту закрывает соединение. ШЕ>Допустим также, что используется опция autocommit. ШЕ>Есть ли какие-либо гарантии, что RDBMS сделает rollback?
Нет, гарантий нету.
MS SQL использует keepalive, поэтому если во время длительной операции с MS SQL пристрелить клиента, то сервер, заметив это, выполнит rollback. Даже посреди стейтмента (скажем, update ... where 1=1 на большой таблице)
Interbase не использовал keepalive. Насильственное отключение клиента во время длительной операции проходило незамеченным; но вот что происходило в конце, когда сервер обнаруживал отвалившегося клиента, я уже не помню. Может и commit.
Но самое печальное, что со стороны клиента понять, успел ли сервер сделать commit до обрыва соединения или нет, решительно невозможно.
Единственная гарантия, которая у вас есть — это что транзакция будет по-прежнему атомарной. Т.е. повторно подключившись вы либо увидите все изменения, либо никаких.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Всё не так.
> У FB транзакции не зависали при timeout?
НИКОГДА.
Это обусловлено архитектурой сервера.
У него нет WAL-журнала, как например у PostgreSQL.
> Не было раньше стороннего софта для прибития зависших транзакций?
Нет и никогда не было.
Состояние LIMBO может возникать (на любых серверах) при 2pc-транзакциях,
но мы ведь не о них сейчас, правда?
Здравствуйте, Alex.Che, Вы писали:
AC>> Коллега, вы бредите. >> А что не так?
AC>Всё не так.
>> У FB транзакции не зависали при timeout?
AC>НИКОГДА. AC>Это обусловлено архитектурой сервера. AC>У него нет WAL-журнала, как например у PostgreSQL.
Вы несёте неквалифицированный бред, совершенно не владея предметом спора.
Ещё раз для упёртых: транзакция ЗАВИСНУТЬ не может!
Как только сработает таймаут по KEEPALIVE, либо же DummyPacketInterval,
транзакция будет помечена как отменённая — ROLLBACK-state.
Здравствуйте, Alex.Che, Вы писали: AC>Ах, как интересно! AC>Вы готовы опубликовать ВОСПРОИЗВОДИМЫЙ тест?
Если найду живой Interbase 5.5 — то буду готов
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Alex.Che, Вы писали: AC>5.5 шел в комплекте с Delphi-5 и был кривой от рождения. AC>Borland настоятельно рекомендовал пользователям обновиться до 5.6
Емнип, 5.6 работал так же.
Разве что в 6.0 что-то починили.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
> Емнип, 5.6 работал так же. > Разве что в 6.0 что-то починили.
Совершенно беспочвенные инсинуации.
Даже в 5.5 это работало так как положено.
Глюки касались иных вещей.
Я ещё раз повторяю:
1. "ЗАВИСАНИЕ" транзакций в IB невозможно принципиально!
2. обрыв коннекта нормально обрабатывается в IB, активная транзакция откатывается.
Антон, вот какого хрена вы пытаетесь спорить, если вы не спец в IB/FB?
