lazy foxПосле того, как вы обломались с предложенной мной объектной моделью и предложили мне абстрагироваться от подробностей реализации, в базе есть такой объект.

Я не заметил никакой объектной модели.

lazy foxДва разными приложения решают две разные задачи с двумя разными БД так, что структура и данные в БД совпадают в каждый момент времени. Напрягитесь.

Это не для среднего ума :-). Если хотите получить ответ по существу корректно поставьте задачу (и желательно без выражений типа "вкладывать смысл в цифры").

Alexey RovdoИ все таки мне кажется что реальная сложность реализации такого механизма будет очень велика, а издержки СУБД возрастут фантастически. СУБД прийдется отслеживать все дерево транзакций, причем делать это всякий раз при выполнении любой транзакции! Почему?

Во-первых, нам как-то прийдется разделять транзакции на те, которые можно откатить и на те, которые откатить нельзя никогда (если я что-то хочу удалить навсегда, то я должен иметь такую возможность).

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

Сам откат закоммиченой транзакции можно рассматривать как новую транзакцию, которая (см. во-вторых).

И если мы говорим об откате закоммиченной транзакции, то логичным будет и требование о возможности "анти-отката", т.е. мы откатили закоммиченную транзакцию, а потом взяли и опять "закатили".

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

И т.д. и т.п..
Все правильно в том числе про REDO. Кроме последнего абзаца. Встретив при откате конфликтную транзакцию можно попросить ее автора откатиться и "освободить дорогу". С тем же можно обратиться к администратору, который может откатить всех куда надо.


Alexey RovdoИнтересно было бы увидеть оценки производительности такой системы в сравнении с традиционными СУБД и оценки места на диске, занимаемого всей этой информацией.
И вот если оценки будут таковы, что традиционные системы окажутся в десятки раз производительнее системы с возможностью отката закоммиченых транзакций, то вряд ли найдутся желающие такими монстрами пользоваться.
Мне самому интересно. Пока я не думаю что будет какой либо проигрыш по сравнению с традиционными системами.

Это потому, что вы пока совсем не думали над реализацией.

Нет, не поэтому.

Как вы отследите ситуацию, когда одна транзакция меняет таблицу А, пользуясь данными из таблицы Б ? Оператор откатил изменения в таблице Б - как вы обнаружите, что надо как-то править данные в А ?

Есть способы. Но имеет смысл говорить, когда будет что показать.

Оператор ошибся, вбивая дату для чистки. Затем десять заданий _прочитали_ эту неправильную дату и почистили сорок таблиц.
Расскажите, как ваша система сможет откатить транзакцию смены даты и восстановить удаленные строки во всех таблицах. Можно без деталей, на пальцах.

Зависит от того каким образом связаны задания и факт вбивания даты зачистки. Как Вы разруливаете такую ситуацию стандартными средствами?

"Разруливаем" мы такую ситуацию просто - выводим оператора за сарай и табельным оружием... разруливаем . :-)

Да...., Жестоко :-). У Вас наверное потому и документация неполная, что разработчики при жизни не успевают ее дописывать.

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

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

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

Логика откатов выходит за пределы логики приложений, и никем никогда в приложение не закладывается. По крайней мере, я таких приложений БД не видел.

И не могли видеть. Управляемые клиентом откаты теперешними базами ведь фактически не поддерживаются.

Кстати, к тому времени как станет "видно, что с такого то времени произошло что то плохое", откатывать назад ВСЕ транзакции будет поздно - если это вообще возможно в условиях проектируемой системы.

Если Вы проектируете системы где нет документации, неизвестно что с БД делает то или иное приложение, и где проблемы могут быть обнаружены только когда уже поздно их исправлять, то согласитесь что "поздно боржоми пить когда печень отвалилась". Здесь никакая СУБД Вам не поможет.

Короче, ваша предполагаемая функциональность может и пригодится в некоей сферической системе в вакууме, с одним сферическим юзером - но программист, который попытается ее использовать, должен быть публично казнен в назидание. Ибо нефиг !

Возьмем хотя бы Оракл. В этом треде уже упоминались и механизм архивных файлов повторного исполнения, и Flash Recovery появившийся в версии 10g (http://www.mid.main.vsu.ru/docs/oracle10/server.101/b10734/rcmflash.htm), и в некоторой степени механизм Workplace. Все это хотя и непрозрачно, с определенными ограничениями, и ориентировано в основном на случаи потери данных, - но все это об откатах. Скажем Flash Recovery может использовать уже и программист.

Получается Оракл работает на потребу сферического узера или это просто издержки западной демократии не приветствующей использование табельного оружия для администрирования БД? :-)

xВ Вашем примере один пользователь меняет одно поле записи, второй - другое. После чего первый откатывает изменение своего поля.

Это меня не устроит даже на уровне read commited.
А на более высоких уровнях, как это уже отмечалось другими авторами, нужно еще отслеживать блокировки других таблиц.

Поэтому, если можно, приведите, пожалуйста, принципиальное описание алгоритма отката (о деталях реализации не спрашиваю - это наверно секрет фирмы :).

Все три транзакции (два изменения и один откат) изолированы как сериализуемые транзакции и все что надо отслеживается.