• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

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

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

    Запись на курс до 25 апреля. Получить промодоступ ...

Как организовать транзакцию?

  • Автор темы GROMILA
  • Дата начала
G

GROMILA

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

Как бы достигнуть надежности?
Может есть какие режимы выполнения серверного агента с возможностью отката изменений?
Может хитрые чексуммы вводить, чтобы можно было идентифицировать сбойную операцию и возобновить при кульных условиях?

Кто как решал поодбные проблемы?
Расскажите плиз.
 
D

Dikobraz Grey

"В Лотус отсутствует понятие транзакции. То есть, если Вам необходимо выполнить логическую совокупность действий как одно целое, и в случае падения операции в середине – все откатить, как было – то у вас это стандартными методами не получится."
 
30.05.2006
1 345
12
BIT
0
"В Лотус отсутствует понятие транзакции..."
".. и это правильно, товарищи!" При наличии репликации она (транзакция) теряет смысл, поскольку репликация осуществляется по-документно, и та пара док-тов, которая согласована в одной реплике, может не быть таковой в соседней.

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

Dikobraz Grey

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

И сколько это будет работать? А конфликтные документы? Нее, это не для Нотеса. У всех свои задачи
 
30.05.2006
1 345
12
BIT
0
И сколько это будет работать? А конфликтные документы? Нее, это не для Нотеса. У всех свои задачи
Нормально будет работать, максимум - на 30% медленнее "непосредственного" редактирования группы док-тов. А конфликтов-то, как раз будет меньше, т.к. агент ОДИН и выполняет запросы по-очереди.

Но ты прав в том (и я тож писАл), что это годится гл.образом для нераспределенной базы, т.е. для класса приложений, где СУБД играют лучше
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!