R>Возможно. Но, кажется, на Linux отваливание клиента обнаруживается системой практически сразу, да вроде и на win это сделано.
Это естественным образом обнаруживается СРАЗУ, если идет обмен клиент-сервер. Например, если сделал запрос — получаешь данные со всей возможной скростью — и связь порвалась — то сервер это сразу обнаружит.
"Подвиснуть" дохлая трнзакция может только при затишье, когда сервер ничего не ждет от клиента и ничего ему писать не собирается. Реально это довольно редкий случай. Но бывает. Dialup например. Но от этого уже никакая архитектура не спасет.
Здравствуйте, Кузьменко Д.В., Вы писали:
КДВ>не надо перекладывать идеологию конкретной реализации MS SQL на другие сервера. Не надо.
Это не идеология, это уже функциональность. С MSSQL'ем и с Oracle'ом можно работать и так и так. С IB, только через клиента.
Та самая "Идеология" в других серверах реализована ни чуть не хуже, только все почему-то предпочитают управлять транзакциями на сервере.
И если бы в IB была такая возможность, то ей бы тоже пользовались, а с клиента управляли бы только в очень исключительных случаях.
Не надо все на идеологию списывать.
КДВ>Чего-чего? Какой откат? read committed пока не кончилась живет без "рестартов". И видит чужие committed изменения.
Да, именно так. Поэтому при RC она может просто подождать, однако при SS так уже не получится.
Здравствуйте, Igor Trofimov, Вы писали:
КДВ>>Ты еще скажи, что в одном коннекте нельзя стартовать несколько транзакций одновременно. КДВ>>MS SQL этого не умеет? Ну и пусть. IB умеет.
iT>Говорят еще более страшную вещь — в одном коннекте нельзя одновременно два запроса фетчить. Если я правильно понял... Это ж вообще ужас.
Точнее говоря, это следствие того, что это нельзя делать в одной транзакции.
С другой стороны, живут же люди как-то. И даже под это философскую базу подводят.
PS. Firebird .Net Provider, по (почти) непонятной причине, сделан так же.
Здравствуйте, Igor Trofimov, Вы писали:
КДВ>>Ты еще скажи, что в одном коннекте нельзя стартовать несколько транзакций одновременно. КДВ>>MS SQL этого не умеет? Ну и пусть. IB умеет.
iT>Говорят еще более страшную вещь — в одном коннекте нельзя одновременно два запроса фетчить. Если я правильно понял... Это ж вообще ужас.
Это все проблемы клиента, а точнее провайдера... Серверу пофигу, он железный. Ему как передадут, так он и выполнит.
Здравствуйте, Кузьменко Д.В., Вы писали: КДВ>не надо перекладывать идеологию конкретной реализации MS SQL на другие сервера. Не надо. КДВ>Ты еще скажи, что в одном коннекте нельзя стартовать несколько транзакций одновременно. КДВ>MS SQL этого не умеет? Ну и пусть. IB умеет. Это не плюс и не минус, просто другая КДВ>схема обработки транзакций.
Интересно. А как сервер узнает, к какой транзакции относится очередной стейтмент?
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Igor Trofimov, Вы писали: iT>"Подвиснуть" дохлая трнзакция может только при затишье, когда сервер ничего не ждет от клиента и ничего ему писать не собирается. Реально это довольно редкий случай. Но бывает. Dialup например. Но от этого уже никакая архитектура не спасет.
Именно поэтому MS SQL делает keepalive все время. Благодаря этому внезапная смерть клиента посреди длиннного апдейт-запроса приводит к немедленному роллбэку.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Привет, Sinclair!
Вы пишешь 14 ноября 2003:
КДВ>> не надо перекладывать идеологию конкретной реализации MS SQL на другие сервера. Не надо. КДВ>> Ты еще скажи, что в одном коннекте нельзя стартовать несколько транзакций одновременно. КДВ>> MS SQL этого не умеет? Ну и пусть. IB умеет. Это не плюс и не минус, просто другая КДВ>> схема обработки транзакций. S> Интересно. А как сервер узнает, к какой транзакции относится очередной стейтмент?
Каждый стейтмент выполняется в контексте определённой транзакции.
Для этого клиент при вызове фунции API, типа isc_dsql_execute2(),
должен в качестве входного параметра передать хендл транзакции.
S>Именно поэтому MS SQL делает keepalive все время. Благодаря этому внезапная смерть клиента посреди длиннного апдейт-запроса приводит к немедленному роллбэку.
Ну дык и в IB интервалы проверки на живость клиента настраиваются... Но на медленных ненадежных каналах слишком частые интервалы — плохо, а значит — вероятны более длинные подвисания дохлых коннектов.. В любом сервере.
Здравствуйте, Igor Trofimov, Вы писали:
S>>Именно поэтому MS SQL делает keepalive все время. Благодаря этому внезапная смерть клиента посреди длиннного апдейт-запроса приводит к немедленному роллбэку.
iT>Ну дык и в IB интервалы проверки на живость клиента настраиваются... Но на медленных ненадежных каналах слишком частые интервалы — плохо, а значит — вероятны более длинные подвисания дохлых коннектов.. В любом сервере.
И не только там, keep alive настраивается и в winNT и в Linux, ничего не мешает настроить так, чтобы выяснялось это мгновенно (ну почти)
А если еще учесть, что самый неудобный режим для IB это конкурентное и непрерывное обновление одних и тех же записей, то можно заключить, думаю, что БД строить надо так, чтобы одна и та же запись обновлялась пореже, и в этом случае повисание транзакции из-за отваливания клиента не так уж и критично.
Здравствуйте, Merle, Вы писали:
M> Та самая "Идеология" в других серверах реализована M> ни чуть не хуже, только все почему-то предпочитают M> управлять транзакциями на сервере.
Стоп. Не надо говорить за всех. Если они не умеют мыслить по другому — это их проблемы. Я знаю массу людей и приложений, которые не используют серверное управление транзакциями в Оракле. И для них это _нормально_.
M> И если бы в IB была такая возможность, то ей бы тоже M> пользовались, а с клиента управляли бы только в очень M> исключительных случаях.
См. выше. Мое понимание прямо противоположное. Принцип программирования типа "запустил команду и забыл, а там хоть трава не расти" мне чужд. Транзакция — это понятие бизнес-логики. А ей управляет только клиент (или сервер приложений). Все остальное — от лукавого.
Здравствуйте, dimitr, Вы писали:
D>Стоп. Не надо говорить за всех. Если они не умеют мыслить по другому — это их проблемы. Я знаю массу людей и приложений, которые не используют серверное управление транзакциями в Оракле. И для них это _нормально_.
Это оправдано, в рамках очень хорошо прописанного среднего звена, которое, к слову, в оракле очень не плохо реализуется в самом сервере.
Так что тут еще надо подумать, что считать управлением транзакций на сервере и на клиенте.
D>См. выше. Мое понимание прямо противоположное. Принцип программирования типа "запустил команду и забыл, а там хоть трава не расти" мне чужд.
Смотря что понимать под "запустил и забыл".
В чем смысл бегать к клиенту и спрашивать "что делать?" в случае ошибки. "Что делать" клиент может сказать в момент старта транзакции. А сервер придет к клиенту и скажет "Ну вот, сделал, дальше че?".
Вот собственно и все разница, но второй вариант череват гораздо меньшими ошибками..
Здравствуйте, Merle, Вы писали:
D>>См. выше. Мое понимание прямо противоположное. Принцип программирования типа "запустил команду и забыл, а там хоть трава не расти" мне чужд. M>Смотря что понимать под "запустил и забыл". M>В чем смысл бегать к клиенту и спрашивать "что делать?" в случае ошибки. "Что делать" клиент может сказать в M> момент старта транзакции.
"Значит так, сервер, сейчас я запущу транзакцию. Потом буду передавать кучу инсертов.
Ежели на каком инсерте выпадет Key violation, то ты не пугайся, это вполне могёт быть.
Ты тогда вместо инсерта запусти апдейт — типа такая запись уже есть, мы её просто обновим.
Но если и при апдейте вылезет какой эксепшн, то тут надо подумать! Если это остатки товаров
получились отрицательные, то ты, сервер, запись эту всё-таки вставь, но в поле "Проведён" выставь
нолик. А вот ежели в записи Клиент указан какой несуществующий, тогда всё, сливай воду.
Пусть админ разбирается. Наверное...
Ну а если ещё что — вываливай окошко с подробным сообщением об ошибке и ... и сам думай, что делать,
потому как никто это окошко не увидит.
Ну, что? Готов? Начинаю:
BeginTransaction() insert(...); insert(...); insert(...); insert(...);"
M>А сервер придет к клиенту и скажет "Ну вот, сделал, дальше че?". M>Вот собственно и все разница, но второй вариант череват гораздо меньшими ошибками..
Здравствуйте, Merle, Вы писали:
M> В чем смысл бегать к клиенту и спрашивать M> "что делать?" в случае ошибки. "Что делать" M> клиент может сказать в момент старта транзакции. M> А сервер придет к клиенту и скажет "Ну вот, сделал, M> дальше че?".
А клиента в этот момент уже нет. Снесли его по ctrl-alt-del, не дождавшись ответа от сервера, аккурат перед возвратом результата от оного. А транзакция уже подтверждена сервером. Спрашивается — что делали, зачем, для кого?...
Я допускаю, что в каких-то случаях старт и подтверждение транзакции на стороне сервера действительно предпочтительнее. Но считать это нормальным режимом работы не стоит. IMHO, разумеется.
P.S. Что-то эта ветка ушла далековато от своих истоков...
Здравствуйте, dimitr, Вы писали:
D>А клиента в этот момент уже нет. Снесли его по ctrl-alt-del, не дождавшись ответа от сервера, аккурат перед возвратом результата от оного.
И не надо. В том-то и фишка, что нафиг клиент не нужен, если транзакция стартовала. Зависимости от клиента нет.
D>А транзакция уже подтверждена сервером. Спрашивается — что делали, зачем, для кого?...
Транзакция действие атомарное. БД — это хранилище данных, транзакции переводят данные из одного состояния в другое, по принципу "все или ничего". И если в процессе перевода клиент отвалится, то транзакция от этого страдать не должна.
Если же, в случае ошибки, транзакция должна ходить к клиенту и спрашивать, что делать, то это, как минимум, черевато потерями производительности.
Для версионника конечно меньшими, чем для блокировочника, но тем не менее и версионнику без подобных хождений жилось бы легче.
D>Я допускаю, что в каких-то случаях старт и подтверждение транзакции на стороне сервера действительно предпочтительнее. Но считать это нормальным режимом работы не стоит. IMHO, разумеется.
Стоит. Это именно и есть нормальный режим работы во всех СУБД, которые это поддерживают.
D>P.S. Что-то эта ветка ушла далековато от своих истоков...
Действительно, пора завязывать.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Не. Это проблемы сервера. AS>Вот в Юконе это дело порешали...
Не в Юконе, а в ADO.Net 2.0 и Юконе, но в сервере там изменения минимальны, на сколько я понял, просто чтобы провайдеру чуть проще было.
Здравствуйте, Alex.Che, Вы писали: AC>Каждый стейтмент выполняется в контексте определённой транзакции.
В принципе, я не вижу никакого логического преимущества в возможности стартовать несколько транзакций в одном соединении AC>Для этого клиент при вызове фунции API, типа isc_dsql_execute2(), AC>должен в качестве входного параметра передать хендл транзакции.
потому как везде при вызове функций API передается хендл заранее подготовленного контекста.
Это может быть connection, connection+transaction, connection+transaction+preparedstatement...
Техническая разница, конечно же, в производительности. Чем гранулярнее контексты, тем дешевле отщепить еще один.
Максимально быстро получается работать с самым полным контекстом (prepared statement).
Когда мы получаем новый prepared statement, можно взять готовый контекст соединения и транзакции.
Если мы хотим получить новую транзакцию, параллельную существущей, то в MS SQL придется создать новое соединение, а в IB, значить, можно готовое использовать. Интересно, велик ли выигрыш?
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
хъ
M>Не в Юконе, а в ADO.Net 2.0 и Юконе, но в сервере там изменения минимальны, на сколько я понял, просто чтобы провайдеру чуть проще было.
Из чего ты это понял?
SQL Server "Yukon" Beta 1 extends the support for multiple active result sets (MARS) in applications accessing the database engine. In earlier versions of SQL Server, database applications could not maintain multiple active statements on a connection when using default result sets. The application had to process or cancel all result sets from one batch before it could execute any other batch on that connection. SQL Server "Yukon" introduces new attributes that allow applications to have more than one pending request per connection, in particular, to have more than one active default result set per connection.
SQL Server "Yukon" Beta 1 introduces a new feature called multiple active result sets (MARS). MARS allows client drivers to have more than one pending request per connection.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Из чего ты это понял?
Из того, что дядька про PDC рассказывал.. Вообщем смотреть надобно, ручками ковыряться.
Мы уже победили, просто это еще не так заметно...
