Ax3sp3 vs Ax4sp2 на примере

[Wamr]

Решил зафиксировать результаты небольших опытов, проведенных на приложениях Ax3sp3 и Ax4sp2 подключенных к серверу MS SQL2005 с БД в режиме 90.

В опытах принимают участие: табличка
aTable с полями
Id - int с уникальным индексом
Value - int без индекса

и 2 жобика

static void Job_b1(Args _args)
{
    aTable  aTable;
    ;

    ttsbegin;
    aTable = aTable::find(12, true); // такая запись есть
    aTable.Value = timenow();
    aTable.update();
    ttscommit;
}

static void Job_b2(Args _args)
{
    aTable  aTable;
    ;

    select aTable
        where aTable.Value == 200; // такой записи нет

    ttsbegin;

    select aTable
        where aTable.Value == 200;

    aTable = aTable::find(12, true);
    aTable.Value = timenow();
    aTable.update();

    ttscommit;
}

Опыт 1
Запускаем 2 клиента аксапты.
В одном из них ставим точку останова на строке aTable.update(); первого джобика и выполняем.
Во втором выполняем джобик2 по шагам.
Ax3sp3 - джобик2 вешается на строке aTable = aTable::find(12, true); до тех пор пока не закончится джоб1.
Ax4sp2 - джоб2 отрабатывает до конца, однако при попытки продолжить джоб1 получаем ошибку:
Невозможно отредактировать запись в aTable (aTable).
Возник конфликт обновления из-за того, что другой пользовательский процесс выполняет удаление записи или изменение одного или нескольких полей в записи.

Опыт 2
Запускаем 2 клиента аксапты.
В одном из них ставим точку останова на строке ttscommit; первого джобика и выполняем.
Во втором выполняем джобик2 по шагам.
Ax3sp3 - на этот раз джобик2 вешается на строке select aTable where aTable.Value == 200; (которая после ttsbegin) до тех пор пока не закончится джоб1.
Ax4sp2 - теперь и здесь джоб2 вешается, но на строке aTable.update(); до тех пор пока не закончится джоб1, а потом выдает туже ошибку:
Невозможно отредактировать запись в aTable (aTable).
Возник конфликт обновления из-за того, что другой пользовательский процесс выполняет удаление записи или изменение одного или нескольких полей в записи.

[mazzy]

а вывод какой?

[Logger]

Цитата:

Сообщение от Wamr

Решил зафиксировать результаты небольших опытов, проведенных на приложениях Ax3sp3 и Ax4sp2 подключенных к серверу MS SQL2005 с БД в режиме 90.

Разве Ax3sp3 может работать с SQL2005 в режиме 90 ? Вы ничего не путаете ? Может имелась в виду Ax3KR3 ?

[CDR]

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

А еще лучше и проще почитать документацию по 4-ке

[kashperuk]

То есть ты хочешь сказать, что точка останова влияет на исполнение запроса?
Что-то слабо верится...
Но попробую на досуге

[Logger]

Цитата:

Сообщение от Wamr

Опыт 2
...
Ax3sp3 - на этот раз джобик2 вешается на строке select aTable where aTable.Value == 200; (которая после ttsbegin) до тех пор пока не закончится джоб1.

Интересно почему ?
Блокировка на странице индекса оказалась ? А откуда ей взяться ? Ведь уровень изоляции транзакции ReadCommited, а не Serialized. Блокировки по строке не должно быть - записи то нет. Либо возможно блокировка легла на страницу или таблицу.

[Logger]

Цитата:

Сообщение от kashperuk

То есть ты хочешь сказать, что точка останова влияет на исполнение запроса?

Не ...
Там просто точкой останова регулируется, проходил update строки или нет. Соответственно разное поведние 4-ки и 3-ки.

Табличка кстати, судя по поведению, настроена на оптимистическую модель конкуренции.

[Владимир Максимов]

Из приведенного описания можно сделать такие выводы:

Ax3sp3

Внутри открытой транзакции все запросы, по умолчанию, не явно, добавляют хинт forupdate и блокируют считываемую запись

Ax4sp2

Либо криво написан метод aTable::find(), либо не работает настройка aTable.selectForUpdate(_update);.

[Logger]

Попробовал на Ax3KR3 Oracle 9

1-й опыт - все как описано.
2-й опыт - повис во 2-м джобе на

   aTable = aTable::find(12, true);

что и следовало ожидать.

Оракл рулит !

Интересно, а как с этим экспериментом в SQL2008 ?

[Logger]

Цитата:

Сообщение от Владимир Максимов

Из приведенного описания можно сделать такие выводы:

Ax3sp3

Внутри открытой транзакции все запросы, по умолчанию, не явно, добавляют хинт forupdate и блокируют считываемую запись

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

[Alexius]

1. В методах find на таблицах часто используется конструкция:

...
myTable.SelectForUpdate(update); 
select myTable where myKey = key;
...

где переменная update = true для выборки записи под обновление.

В Ax3sp3 : при выполнении сразу блокируется запись (страница, таблица) на обновление, т.е. в запросе на SQL сервер присутствует хинт UPDLOCK.

В Ax4sp2 : такой блокировки не происходит.

2. В Ax3sp3, при настройках по умолчанию, вне транзакции используется грязное чтение (READ UNCOMMITED), а внутри чистое (READ COMMITED)

В Ax4sp2 : используется только чистое чтение (READ COMMITED)

[mono]

Цитата:

Сообщение от Wamr

В опытах принимают участие: табличка
aTable с полями
Id - int с уникальным индексом
Value - int без индекса[/I]

Думаю, что если отключить OCC для таблицы "aTable", то поведение AX4SP2 не будет отличаться от AX3SP3. Как говорится RTFMMF.

[Wamr]

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

Logger,
именно SP3 (без KR3)
поиск по неиндексированому полю = TableScan, а значит и подвисание на заблокированной строке при уровне изоляции ReadCommited

CDR, спасибо, но мне пока и sp_lock хватает

Иван,
уровень блокировки на строку поднимается до эксклюзивного после выполнения update

Владимир,
я бы сказал, что в ax3sp3, запрос выполненный за пределами транзакции равноценен запросу в транзакции с хинтом selectLocked(false), то бишь NOLOCK
Это можно назвать одним из выводов


Отключение OCC на таблице делает ax4sp2 похожим на ax3sp3+Oracle9, а не ax3sp3+SQL2005

[Wamr]

Проверил AX4sp2 с отключённым OCC.

Опыт 1 + Опыт 2
джобик2 вешается на строке aTable = aTable::find(12, true); до тех пор пока не закончится джоб1.


Аналогично себя ведет Ax3sp3 с Oracle9
и Ax3sp3 с SQL2005 при включении на БД snapshot isolation (не тестированное сочетание)