vybegalloПроблема "только" в том, чтобы распознать, какие транзакции конфликтуют, а какие - нет. Как вы себе представляете такое распознавание ?

Действительно это проблема, но она решаема.

2serg99Вы мне скажите - у вас при "откате" застарелой транзакции триггеры отрабатывать будут ?

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

tygra авторВопрос в том можно ли в принципе удалить клиента по логике приложения? Допустим можно. Можно ли ввести нового клиента? Разумеется. Если приложение корректно отрабатает ситуацию когда я вручную удаляю клиента, а затем вручную добавляю клиента эквивалентного удаленному, то не вижу основы для бардака.
И что, где тут откат чего-либо?
Я полагал что здесь ясно о чем я говорю. Если в приведенном примере новый клиент появляется как откат операции "удалить клиента", то бардака не получается.

tygra авторЕсли какие то отчеты должны соответствовать первичным данным, то они периодически перезапускаются.
Т.е. если вы запустите отчет за один и тот же день. но попадете то на откат транзакции, то на "закат" :) то окажется, что один и тот же отчет за один и тот же момент содержит разные данные. И какой из ни правильный?
Вы определитесь о чем Вы говорите - об одном и том же дне, или об одном и том же моменте. Работа с отчетами ничем не отличается от обычной ситуации когда во время отчета операторы то добавляют что нибудь в базу, то удаляют что нибудь из базы.

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

Я естественно говорю не о конфликте транзакций в смысле их изоляции. Я говорю о конфликте в смысле логики отката. Допустим у меня есть таблица яблок с атрибутами Цвет и Вес. Я у определенного яблока поменял цвет с желтого на зеленый. Другой клиент после этого поменял вес яблока с 100г до 200г. Я вдруг вспомнил, что зря поменял цвет и задал откат последней своей транзакции. В результате Цвет яблока вернется к желтому.
Теперь предположим что другой клиент после меня не Вес изменил, а так же Цвет и у того же яблока (допустим с зеленого на красный). Теперь моя попытка откатить транзакцию (сделать Цвет желтым) будет означать не только откат моих действий, но и действий другого клиента, что противоречит логике отката (я то хочу откатить только "свои" действия). Это я и называю конфликтом транзакций.

tygra Это ваша проблема. Уже скоро неделя будет, как вам это вдалбливают в голову

-- Tygra's --

Вы главное не волнуйтесь так сильно. Нервные клетки не восстанавливаются.

lazy foxserg99, вы действительно не можете представить себе две совершенно идентичные по структуре и данным базы с совершенно различной логикой блокировки откатов, зависящей от времени коммитов, причем уже неизвестно как?

Представить себе я могу что угодно. Я только не понимаю почему Вы считаете, что последовательность коммитов обязательно должна быть неизвестной. Представьте себе что она известна.

Получается. Хотя-бы потому, что у клиента будет новый ID. А если на клиенте ничего не было навешено - то и откатывать нечего, добавляй нового.

Так что проще нажать кнопку UNDO или заново набивать целую страницу реквизитов клиента?

Не важно, о чем, но уже прошедшем. И получится, что за позавчерашний день сегодня отчет будет один, а завтра другой. И оба правильные

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

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

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

lazy fox serg99 lazy foxserg99, вы действительно не можете представить себе две совершенно идентичные по структуре и данным базы с совершенно различной логикой блокировки откатов, зависящей от времени коммитов, причем уже неизвестно как?

Представить себе я могу что угодно. Я только не понимаю почему Вы считаете, что последовательность коммитов обязательно должна быть неизвестной. Представьте себе что она известна.

Она известна и совпадает в обоих базах. Но клиенты разные.

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

lazy foxЯ не имел ввиду пользователей ) Два клиента (прога такая) вкладывают различный смысл в одни и те же цифры. Для одного 1=пришел, а для второго 1=ушел. По расписанию. Истории расписания нет (не ведется).

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

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

Мы рождены что бы сказку сделать былью :-).

А в чем вы не хотите меня переубеждать? Я не вижу ничего такого

А я уже и не пытаюсь переубеждать.

xА вот если это и есть описание логики отката, то я вряд ли смогу его использовать

А какая логика отката Вас бы устроила?