Обсуждение:Транзакция (информатика)

Уровни изолированности транзакций Есть отдельная статья.

-1

Статью следует полностью переписать. Изложение базируется на SQL92, то есть устарело на 15 лет, материал дается с точки зрения сугубого блокировочника, фундаментальные сведения практически полностью отсутствуют, используемые термины не определены (например, "фантомы"), зато притянуты распределенные транзакции и журналы транзакций - по каждой из этих тем можно написать хорошую главу. В целом такое впечатление, что кто-то поверхностно нахватанный наспех скомпилировал абзацы из книжки типа "SQL для дебилов".

Зашел сюда, дабы кинуть человеку ссылку на определение транзакции - но ссылаться на этот материал просто смешно.

Представлюсь - softwarer, со мной можно побеседовать по емейлу softwarer@nm.ru или на форумах www.sql.ru

Может быть, поможете, напишите так как должно быть и потом кинете ссылку на написанный Вами материал тому человеку. MaxiMaxiMax 08:53, 27 октября 2006 (UTC)

Вообще-то определение транзакции не имеет ничего общего с SQL. Причем тут SQL92 - вообще не понятно. SQL - это декларативный язык описания ЗАПРОСОВ. Транзакции - это концептуальное понятие в информатике, в данном узком смысле. Хотя согласен, что по теме "распределенные транзакции" запросто можно написать отдельную статью, и даже несколько. Но хотелось бы при такой, гм, непрофессиональной обозленности, увидеть чуть больше конструктивной критики. Кстати, Вам ведь ничего не стоило, вместо описания тут своих претензий, добавить статью "Фантомы (транзакция)". Для этого Википедия и задумывалась, нет? Успехов. Exceeder 03:05, 30 октября 2006 (UTC)

Насчет написать как должно быть - это довольно нехилый объем работы, в том числе включая разбирание с разметкой, принятым стилем изложения материала итп. Не уверен.

Насчет "при чем тут SQL92" - видите ли, SQL92 - это обиходное название соответствующего ANSI стандарта, и хотя я понимаю, что Вас может смутить этот факт, посвящен этот стандарт не только "языку запросов SQL". В частности, именно этот стандарт ввел критерии, изложенные в статье в параграфе "Изоляция транзакций". В настоящее время этот материал является "давно устаревшим".

"Это не я заговорил про SQL, это вы заговорили" :) Я неплохо знаком со стандартом, в том числе и 2003-м, но я виноват, что неоднозначно сформулировал свои мысли в предыдущем ответе. Уровни изоляции транзакций в таком виде были введены в 1977г в "...Degrees of Consistency in a Shared Database" by J.Gray, R.Lorie и др. и-таки не имели ничего общего с SQL. Я согласен, что в SQL92 неудачно сформулированы определения, выдранные из этой работы, эффективно приведшие к неоднозначности в понимании. Однако данная секция об уровнях изоляции (которую, кстати, не я написал), вполне допустима в этой статье, как наиболее распространненный подход к пониманию уровней изоляции. Другое дело, что ее обязательно надо расширить, указав на все феномены, включая фантомное чтение. А также показать такие уровни, как Snapshot Isolation. Однако опять же, вопрос в том, насколько энциколпедическая статья должна углубляться в детали имплементации, или достаточно ограничится общераспространенными, хоть и весьма приблизительными понятиями. С другой стороны, все только поприветствуют ваше собственное предложение разбивки статьи на секции, это займет каких-то несколько минут, чтобы поместить его сюда, в дискуссию. А желающие наполнить содержимым, возможно, найдутся. Очевидно, что важно мнение любого человека, читающего и тем более являющегося экспертом области статьи.Exceeder 22:21, 30 октября 2006 (UTC)

Свойства serializable транзакций

Человек добавил ACID принципы сюда, как "Свойства serializable транзакций" хотя для этого есть отдельная статья, ну и ACID это не только свойства таких транзакций. Плюс, заголовок тоже неверный и содержит ненужное английское слово. Я не люблю удалять осмысленные чужие правки просто так, какие будут предложения? Exceeder 14:15, 25 января 2007 (UTC)

Журнал транзакций

По поводу того что версионнику не нужен журнал транзакций- достаточно сомнитительное утверждение. Вот Оракл, например, версионник, а журнал транзакций есть. Вы можете сослаться на какие-то источники этой идеи? Имхо версионник vs блокировочник относится к вопросам изоляции, а журнал транзакций это про durability. Bibikoff 12:05, 20 марта 2007 (UTC)

Версионник, можно сказать, имеет только журнал транзакции - в БД лежат не только данные в актуальном на момент последнего коммита виде, но и предыдущие, если в них есть заинтересованность (посмотрите описание структуры, например, файла БД Firebird или Interbase). Соответственно журнал транзакций как метод отката записанных в БД, но не закомиченных в результате сбоя данных просто не нужен - файл БД (конечно, при условии корректно работающего железа и неглючного сервера, а также отсутствия кеширования на запись) в любой момент времени консистентен (возврат из вызова COMMIT гарантирует, что данные записаны на диск). Что же касается durability, то я не понял, причём тут длительность... Можно какой-нить аналогичный русскоязычный термин? Длительность транзакции? Так опять же - в файле БД версионника все необходимые для работы версии записи лежат в самом файле БД, новые данные никогда не затирают старые данные, пока старые данные не будут признаны мусором (именно поэтому, кстати, при удалении большого массива данных из БД файл может вырасти, хотя вроде как этого от него никто не ждёт: на самом деле удаление - это тоже модификация записи, а новая версия записи всегда кладётся на новое место). С точки зрения детализации знаний обо всех этих процессах могу порекомендовать сайт www.ibase.ru. Собственно, желание некоторых пользователей версионника получить-таки лог транзакций обычно связан с желанием научиться откатывать закомиченные транзации либо иметь детальный лог изменения БД для какого-либо анализа (я, правда, сильно сомневаюсь, что такой анализ кто-либо будет вести). Что касается оракла, то насколько он является чисто версионником, я не знаю, и зачем там используется журнал транзакций - без понятия. Но сильно подозреваю, что он там наличествует потому, что оракл не является в чистом виде версионником (но могу ошибаться). Sergey A. Fadeyev 08:06, 21 марта 2007 (UTC)

1) под durability я имел в виду D из ACID.

2) "...Соответственно журнал транзакций как метод отката записанных в БД, но не закомиченных в результате сбоя данных просто не нужен - файл БД (конечно, при условии корректно работающего железа и неглючного сервера, а также отсутствия кеширования на запись) в любой момент времени консистентен..." - скорей всего это не так, есть туча нюансов как раз про кэширование, отложенную запись, соображения производительности.

3) "...Соответственно журнал транзакций как метод отката записанных в БД, но не закомиченных в результате сбоя данных..." журнал транзакций обычно инструмент "перенаката", а не отката. Для отката используется "сектор отката".

4) повторюсь, термин "версионник" относится к тому как реализована изоляция (I в ACID). Обычно этот подход противопоставляется "блокировочнику", что также является подходом к реализации изоляции. На практике чистых версионников (не использующих блокировки) не бывает. На sql.ru несколько месяцев назад была дискуссия на эту тему с участием достаточно уважаемых людей.

5) В Interbase нет transaction-лога? Сомневаюсь.

Transaction log используется в IB для для анализа кто изменил данные? Тоже сомневаюсь. Для этого trace есть.

Предлагаю вообще переформулировать раздел про лог транзакций. Точнее заменить его на раздел Реализация. Ведь лог транзакций - не единственный механизм обеспечивающий транзакционность в СУБД. Сейчас эта мысль размазана так, что практически ничего не понятно.

Думаю, надо перевести из статьи http://en.wikipedia.org/wiki/ACID раздел про Implementation. Там вроде достаточно грамотно изложено.

Ещё предлагаю эту дискуссию на страницу обсуждения статьи перенести.

Bibikoff 10:25, 21 марта 2007 (UTC)

1) В этом смысле, как я уже сказал, возврат из COMMIT гарантирует запись данных в файл БД, если не используется кеширование на запись. Конечно, если используется схема работы без промежуточных хранений (в версионнике это вполне возможно и логично).

2) Что значит "не так", если именно так и есть? Отложенная запись при работе с БД суть неизлечимое зло (точно так же может не записаться и лог). Но в случае, если кеширование работает так, что отложенная запись не может быть потеряна даже при форс-мажорах, не связанных с выходом из строя самого хранилища данных - файл БД действительно всегда содержит достаточно информации для корректной работы, по другому просто не бывает - логика такая.

3) Что такое "перенакат"? Если изменение уже закомиченно и записано в БД - что куда ещё перенакатывать? Если же мы говорим о ситуации, когда вначале запись производится во временный лог, клиенту сигнализируется, что всё записано, а потом уже сервер начинает реально писать в БД - тут да, перенакат нужен. Вот только версионник по своей логике устроен так, что временного лога не нужно - можно сразу в БД писать. По крайней мере, именно так устроена работа БД в Firebird и Interbase. Возможно, в других реализациях используется промежуточный подход "вроде как и версии есть, но не в БД, а рядом, в логе" - тут я не в курсе, ничего путного сказать не могу, но на мой взгляд, это половинчатая реализации идеи версионирования данных.

4) Ссылку на дискуссию можно? Чтобы ознакомиться с вопросом... На самом деле версионник, как я понимаю, исключает или уменьшает появление неоправданных автоматических блокировок (полное отсутствие блокировок невозможно в принципе при конкурентной работе - например, если один данные поменял и не закоммитился, то другой их поменять никак не сможет (до коммита первого или вообще - зависит от уровня изоляции), если не принят другой способ разрешения коллизий изменения).

5) Предлагаю спорить о вкусе устриц с теми, кто их ел. Учитывая то, что я этим сервером (точнее, его потомком - Firebird'ом), пользуюсь далеко не первый год, могу ответственно заявить - transaction log'а в нём нет, все его функции выполняет сам файл БД. Собственно, именно поэтому я и сделал свою правку, что изначально в статье было написано так, будто бы это единственно возможный путь работы, и по-другому не бывает вообще. Возможно, я не совсем корректно написал - предлагаю более знающим людям меня поправить.

По поводу переформулирования - категорически согласен. Но я сейчас этим заняться не смогу.

Sergey A. Fadeyev 11:14, 21 марта 2007 (UTC)

Я дописал и переименовал, как предложено. Пожалуйста, проверьте - покритикуйте. Exceeder 18:36, 23 марта 2007 (UTC)

По поводу копивио

Я лично сам написал текст, переработав английскую и немецкую вики на тот момент. В данном случае википедия была первоисточником, а не наборот. Что не сложно установить по датам. Просьба к администратору убрать тэг. Exceeder 17:18, 14 марта 2008 (UTC) P.S. Извиняюсь, я посмотрел не на тот блок текста. Да, характеристики транзакций были добавлены позже и, похоже, это copyvio. Exceeder 17:23, 14 марта 2008 (UTC)

Вот изменение, которое copyvio [[1]] Автор: Longman. Exceeder 17:28, 14 марта 2008 (UTC)

Нерабочие ссылки?

Пожалуйста, проверьте следующие ссылки на внешние ресурсы: http://zeus.sai.msu.ru:7000/database/articles/aries/ (раздел Примечания, п. 3) 93.80.83.23 17:19, 18 ноября 2016 (UTC)

Пометил ссылку как недоступную. Евгений Мирошниченко 17:36, 18 ноября 2016 (UTC)