su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From :  Sergey Pratch                       2:5020/400     28 Aug 2002  13:51:09
 To : Tengiz Kharatishvili
 Subject : Hа: Отчёты, сериализуемость, фантомы и MS SQL
 -------------------------------------------------------------------------------- 
 

 Hi!
 
 "Tengiz Kharatishvili" <Tengiz.Kharatishvili@gte.net> сообщил/сообщила в
 новостях следующее: news:akhugv$1cs8$1@ddt.demos.su...
 
 > " Sergey Pratch" <sltoopls@kot.poltava.ua> wrote in message
 > news:akg8q9$avu$1@news.kot.poltava.ua...
 > Спасибо. Я просмотрел. Перевод небезупречный. Hе столько с технической, а
 
 со
 
 > стилистической точки зрения: это не очень хороший русский язык, а местами
 > просто жутко корявый русский язык. И эта корявость может приводить к
 > техническим абсурдам. Поэтому и оставляет намного больший зазор для
 > интерпретаций, чем это было в оригинале. Вот только один пример:
 > "inconsistent analysis problem" следует переводить как "проблема
 > несогласованного анализа", а не как "проблема анализа несогласованности".
 
     Я все таки на ночь глядя просмотрел статью и могу сказать следующее: на
 самом деле в статье не критика уровней изолированности в стандарте, а
 критика приведенных описаний феноменов. Hо! Станадарт не стандартизирует
 феномены (опять "масло маслянное"), а приводит их в качестве примера.
 >
 > >     Dirty write - ИМХО это не феномен, это полное отсутствие транзакций,
 
 и
 
 > > это следует из самого определения транзакций. иначе никто не знает, что
 
 он
 
 > > коммитить или что он откатывает.
 > >
 > >     Зачем обсуждать то, что должно быть по определению. или это типа
 > "масло
 > > маслянное".
 > >
 >
 > Dirty Write не создаёт сложностей при фиксации, когда восстанавливаемость
 > обеспечивается журналом транзакций с write-ahead logging. Проблематичен
 > только откат. А для версионника без журнала всё наоборот: с откатом
 
 проблемы
 
 > нет - при аборте новые значения просто никогда не попадут в базу. Поэтому
 > одна из целей, поставленная авторами статьи, уточнить определения аномалий
 > затем, чтобы эти определения оказались полностью независимы по отношению к
 > механизму, обеспечивающему транзакционную семантику. Будь это
 
 блокировочник,
 
 > версионник или что-либо другое.
 
     По определению, завершающая фаза транзакции должна сохранить все
 изменения в БД, сделанные этой транзакцией! Именно этой. Если разрешить
 грязную запись, то мы тем самым разрешаем комитить нечто, что произошло в
 это время, но никак не те изменения которые сделала именно эта транзакция.
 >
 > Поэтому очевидное и интуитивное понимание того, что, скажем, для
 > блокировочника разрешить Dirty Write равноценно полной ж... следует сразу
 > забыть. Потому, что завтра придёт очередной Джим Грей и придумает новый
 > механизм, не сводящийся ни к какой комбинации известных. И опять Беренсону
 
 с
 
 > Бернштайном придётся писать ещё одну статью с критикой недальновидно
 > сформулированных определений аномалий, которые подразумевали (хотя явно и
 
 не
 
 > указывали) блокировочник или версионник.
 
     Просто не согласен. Разве, что в корне изменить само понимание
 транзакции, не как что-то четкое и конкретное, а как что-то расплывчастое и
 непонятное.
 >
 > >     Hу хорошо, объясни мне почему история H1 в главе 3 (ровно как и все
 > > последующие) не подходит не под одно поределение стандарта. Уж не
 
 потому,
 
 > > что в примере, который приведен в стандарте, Т1 завершается откатом, а в
 > H1
 > > комитом? Так в стандарте определен уровень "READ COMMITED", а не
 > "PROTECTION
 > > OF DIRTY READ AGAINST CONSEQUENT ROLLBACK". Т.е. предполагается, что на
 > этом
 > > уровне изоляции все данные, которые были прочитаны, были до момента
 
 чтения
 
 > > закомичены.
 >
 > Если говорить о READ COMMITTED, то по определению - это защита от A1. Хотя
 > название уровня и совпадает с реальным поведением в случае блокировочника
 > (исключительная блокировка держится до конца транзакции - поэтому
 
 прочитать
 
 > грязные данные действительно нельзя), на самом деле название следует
 > понимать как заклинание, выбранное (исторически) для этого уровня
 
 изоляции,
 
 > но которое в общем случае нельзя понимать буквально - "не читай
 > незафиксированных данных". Потому что в общем случае буквальное понимание
 > может быть полностью лишённым смысла.
 
     Да, вариантов развития по сценарию феномена А1 - более чем достаточно,
 там и нашим внукам хватит вариантов их описывать. Если же тупо следовать
 защите от феномена А1, то надо не блокировать чтение грязных данных, а
 запретить откат транзакции, эти изменения сделавшей. Действительно феномем
 А1 описан только в одной из вариаций. Hо защита от именно такой вариации
 покрывает и остальные. Hапример, никто не мешает транзакции Т1 модицировать
 даные повторно или вообще удалить запись. Поэтому уровень изоляции определен
 абсолютно правильно - READ COMMITED - читать только подтвержденные данные.
 
 >
 > И как показывают авторы, уровни ANSI, определённые как защита от аномалий
 > A1, A2, A3, не обеспечивают сериализации для историй H1, H2, и H3 потому
 
 что
 
 > они не сводится к указанным аномалиям. Однако небольшая коррекция A1, A2,
 > 3  - результатом которых являются P1, P2, P3, и которая ровным счётом
 
 ничего
 
 > не меняет для систем, основанных на блокировках, ситуацию с H1, H2, H3
 > исправляет уже в общем виде, вне зависимости от механизмов сериализации.
 
     То, что приводят авторы статьи - это не кореекция, а просто раскрытие
 ситуаций в горизонтальной плоскости. Hо критика поддаются не уровни
 изолированности, а определения феноменов. И то, только по той причине, что
 авторы считаю моментом возникновения феномена момент завершениея транзакции,
 модифицировавшей данные. Тогда как сам по себе феномен возникает в момент
 w1(x), r2(x), аналогично для всех остальных уровней.
 >
 > > А то, что пример в стандарте такой - так стандарт не учебник, и
 > > то, что его разработчики предусмотрели в стандарте текстовый пример,
 
 пусть
 
 > и
 > > не охватывающий весь спектр ситуаций, так и на том спасибо.
 > >
 >
 > Да, стандарт не учебник. Hо отличается он от учебника совсем не в ту
 > сторону. Он намного хуже учебника. Задача стандарта - быть максимально, до
 > сводящей скулы скукоты, исчерпывающим. Hи одна делать не должна быть
 
 забыта.
 
 > ANSI SQL 99 - это огромный по объёму документ. Зачем это делается - да
 > затем, что стандарт - это эталон, который должен быть максимально точным и
 > который в идеале не должен допускать никакой неоднозначности.
 
     Тоже не совсем согласен. Если стандартом требуется определить прибор,
 необходимый для измерения некой величины (например ГОСТ на высокооктановые
 сорта бензинов), то просто указывается требуемая точность прибора. И это
 вовсе не значит, что стандарт обязан приводить последствия если для
 измерений будут использоватся с меньшей точности или не такого типа. Это не
 задача стандарта описывать несоблюдения его.
 --
 С уважением,
 Сергей Прач
 
 =================
 Please, send you private mail to: s_pratch@mail.ru
 --- ifmail v.2.15dev5
  * Origin: LtawaSoft (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    Отчёты, сериализуемость, фантомы и MS SQL   Tengiz Kharatishvili   25 Aug 2002 22:09:51   Re: Отчёты, сериализуемость, фантомы и MS SQL   Liliya Huff   26 Aug 2002 01:07:32   Re: Отчёты, сериализуемость, фантомы и MS SQL   Andrew Grachyov   26 Aug 2002 22:10:00   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   26 Aug 2002 16:25:42   Re: Отчёты, сериализуемость, фантомы и MS SQL   Tolik Tentser   26 Aug 2002 19:00:11   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   26 Aug 2002 20:29:37   Re: Отчёты, сериализуемость, фантомы и MS SQL   Igor Kuhtin   27 Aug 2002 14:45:06   Re: Отчёты, сериализуемость, фантомы и MS SQL   Dmitry Novikov   28 Aug 2002 11:59:17   Re: Отчёты, сериализуемость, фантомы и MS SQL   Igor Kuhtin   28 Aug 2002 17:57:47   Re: Отчёты, сериализуемость, фантомы и MS SQL   Dmitry Novikov   28 Aug 2002 21:17:05   Re: Отчёты, сериализуемость, фантомы и MS SQL   Igor Kuhtin   29 Aug 2002 08:47:33   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   29 Aug 2002 15:39:43   Re: Отчёты, сериализуемость, фантомы и MS SQL   Igor Kuhtin   30 Aug 2002 08:40:51   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   30 Aug 2002 14:40:09   Re: Отчёты, сериализуемость, фантомы и MS SQL   Tolik Tentser   28 Aug 2002 18:36:07   Re: Отчёты, сериализуемость, фантомы и MS SQL   Igor Kuhtin   28 Aug 2002 18:31:01   Hа: Отчёты, сериализуемость, фантомы и MS SQL    Sergey Pratch   29 Aug 2002 01:40:47   Re: Hа: Отчёты, сериализуемость, фантомы и MS SQL   Igor Kuhtin   29 Aug 2002 09:01:11   Hа: Hа: Отчёты, сериализуемость, фантомы и MS SQL    Sergey Pratch   29 Aug 2002 15:29:30   Hа: Hа: Отчёты, сериализуемость, фантомы и MS SQL   Petr Ageev   30 Aug 2002 08:35:00   Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Matsievsky   30 Aug 2002 16:01:14   Re: Hа: Hа: Отчёты, сериализуемость, фантомы и MS SQL   Igor Kuhtin   30 Aug 2002 08:36:33   Re: Hа: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Matsievsky   29 Aug 2002 15:17:11   Re: Hа: Отчёты, сериализуемость, фантомы и MS SQL   Igor Kuhtin   30 Aug 2002 08:45:27   Re: Hа: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Matsievsky   31 Aug 2002 10:42:29   Re: Hа: Отчёты, сериализуемость, фантомы и MS SQL   Igor Kuhtin   31 Aug 2002 11:38:32   Re: Hа: Отчёты, сериализуемость, фантомы и MS SQL   Tolik Tentser   31 Aug 2002 19:47:07   Re: Отчёты, сериализуемость, фантомы и MS SQL   Liliya Huff   26 Aug 2002 20:19:28   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   26 Aug 2002 20:52:12   Re: Отчёты, сериализуемость, фантомы и MS SQL   Liliya Huff   27 Aug 2002 00:53:59   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   27 Aug 2002 16:30:40   Re: Отчёты, сериализуемость, фантомы и MS SQL   Andrew Grachyov   26 Aug 2002 22:15:00   Re: Отчёты, сериализуемость, фантомы и MS SQL   Tengiz Kharatishvili   26 Aug 2002 19:24:31   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   26 Aug 2002 20:29:36   Hа: Отчёты, сериализуемость, фантомы и MS SQL    Sergey Pratch   26 Aug 2002 22:42:03   Re: Отчёты, сериализуемость, фантомы и MS SQL   Tengiz Kharatishvili   27 Aug 2002 05:38:48   Hа: Отчёты, сериализуемость, фантомы и MS SQL    Sergey Pratch   27 Aug 2002 10:35:52   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   27 Aug 2002 17:01:17   Re: Отчёты, сериализуемость, фантомы и MS SQL   Tengiz Kharatishvili   27 Aug 2002 19:03:23   Hа: Отчёты, сериализуемость, фантомы и MS SQL    Sergey Pratch   27 Aug 2002 20:20:37   Re: Отчёты, сериализуемость, фантомы и MS SQL   Tengiz Kharatishvili   28 Aug 2002 11:36:45   Hа: Отчёты, сериализуемость, фантомы и MS SQL    Sergey Pratch   28 Aug 2002 13:51:09   Re: Отчёты, сериализуемость, фантомы и MS SQL   Tengiz Kharatishvili   28 Aug 2002 20:40:24   Hа: Отчёты, сериализуемость, фантомы и MS SQL    Sergey Pratch   29 Aug 2002 01:40:47   Re: Отчёты, сериализуемость, фантомы и MS SQL   Tengiz Kharatishvili   29 Aug 2002 05:33:15   Re: Отчёты, сериализуемость, фантомы и MS SQL   Liliya Huff   28 Aug 2002 20:34:20   Hа: Отчёты, сериализуемость, фантомы и MS SQL    Sergey Pratch   29 Aug 2002 01:40:46   Re: Отчёты, сериализуемость, фантомы и MS SQL   Liliya Huff   30 Aug 2002 18:01:49   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   27 Aug 2002 16:30:40   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   27 Aug 2002 17:25:41   Re: Отчёты, сериализуемость, фантомы и MS SQL   Andrew Grachyov   28 Aug 2002 00:03:00   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   28 Aug 2002 18:19:46   Re: Отчёты, сериализуемость, фантомы и MS SQL   Tengiz Kharatishvili   26 Aug 2002 22:09:32   Re: Отчёты, сериализуемость, фантомы и MS SQL   Liliya Huff   27 Aug 2002 00:41:49   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   27 Aug 2002 17:01:16   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   27 Aug 2002 17:25:41   Re: Отчёты, сериализуемость, фантомы и MS SQL   Tengiz Kharatishvili   27 Aug 2002 19:15:32   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   27 Aug 2002 19:40:04   Re: Отчёты, сериализуемость, фантомы и MS SQL   Tengiz Kharatishvili   27 Aug 2002 20:20:38   Re: Отчёты, сериализуемость, фантомы и MS SQL   Vladimir Pavlikov   28 Aug 2002 17:41:03   Re: Отчёты, сериализуемость, фантомы и MS SQL   Liliya Huff   27 Aug 2002 21:11:15   Re: Отчёты, сериализуемость, фантомы и MS SQL   Tengiz Kharatishvili   28 Aug 2002 08:06:49