SystemSequences - Выделение RecId

[kashperuk]

Пытаюсь понять логику. Пока не дошло

static void JobSystemSequenceNextVal(Args _args)
{
    SystemSequence SystemSequence;   
    ;
 
    SystemSequence = new SystemSequence();
    print SystemSequence.getCacheSize();
    print SystemSequence.nextVal(tableNum(InventTable));
    pause;
}

Результат:
250
139565347

Если выполнить еще раз, получаю, ессно, 139565348

При этом смотрю в таблицу SystemSequences. В NextVal для RecId вижу 139565770

Я, конечно, не физ.мат. заканчивал, но даже мне видно, что

139565770 - 139565347 > 250, а конкретно равно 423

Вопрос1: Как же это так получается?
Вопрос2: Кроме как методом setCacheSize, как можно управлять параметром NextVal? В конфиг. утилите AOS есть для этого поле? Какое?

Спасибо

[kashperuk]

На всякий случаай напишу версию системы и СУБД:
AX 3.0 SP5 KR2, SQL Server 2005 SP2

[mazzy]

См. также Вставка строк в таблицы Аксапты сторонними средствами

Была еще одна ветка, где разжевывался алгоритм генерации RecID.
Что-то не могу найти.

[kashperuk]

Хм. Спасибо конечно, ссылку эту я раньше не видел.
Но все это уже давно известно.

Мне бы причину этого странного поведения выяснить. Или выяснить, что я не прав и оно совсем не странное.

[kashperuk]

Немного реабилитирую работу класса SystemSequences перед читателями.

static void JobSystemSequenceNextVal2(Args _args)
{
    SystemSequence  systemSequence;
    RecId           recIdBefore, recIdAfter;
    ;
    systemSequence = new SystemSequence();
    systemSequence.flushCache();
    recIdBefore = systemSequence.nextVal();
    systemSequence.flushCache();
    recIdAfter = systemSequence.nextVal();

    info(strFmt("Размер буфера: %1", systemSequence.getCacheSize()));
    info(strFmt("След. значение: %1", recIdBefore));
    info(strFmt("След. значение: %1", recIdAfter));
    info(strFmt("Разница: %1", recIdAfter - recIdBefore));
}

Это задание выдает след. результаты:

Info Сообщение (16:06:31) Размер буфера: 250
Info Сообщение (16:06:31) След. значение: 32285687
Info Сообщение (16:06:31) След. значение: 32285937
Info Сообщение (16:06:31) Разница: 250

То есть вроде как все ОК.
Правда при этом остатется в силе мой изначальный вопрос. Как так получается у меня?

[Ed1k]

Цитата:

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

250
139565347

Если выполнить еще раз, получаю, ессно, 139565348

При этом смотрю в таблицу SystemSequences. В NextVal для RecId вижу 139565770

Я, конечно, не физ.мат. заканчивал, но даже мне видно, что

139565770 - 139565347 > 250, а конкретно равно 423

Вопрос1: Как же это так получается?

Так а чего удивительного, кто-то позже спросил и себе 250

[kashperuk]

Цитата:

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

Так а чего удивительного, кто-то позже спросил и себе 250

AFAIK, вообще АОС выделяет RecId для всех клиентов. То есть кэш в 250 значений - на всех клиентов, а не на одного.
Соответственно не мог
Более того, я это тестировал в новой компании, я был единственным активным пользователем.

[George Nordic]

А если несколько АОСов?

[kashperuk]

Цитата:

Сообщение от George Nordic

А если несколько АОСов?

Про несколько речь не идет, так как у нас АОС всего один.

[ivas]

Цитата:

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

При этом смотрю в таблицу SystemSequences. В NextVal для RecId вижу 139565770

у меня
SystemSequence.flushCache();
SystemSequence.nextVal();

ax 1753711625 db 1753711875 разница 250

SystemSequence.nextVal();

ax 1753711626 db 1753712125 уже 499

SystemSequence.nextVal();

ax 1753711627 db 1753712125 498

[ZVV]

Цитата:

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

Вопрос2: Кроме как методом setCacheSize, как можно управлять параметром NextVal? В конфиг. утилите AOS есть для этого поле? Какое?

Насколько я знаю, нет такого управляющего места, эта цифра по умолчанию похоже зашита в ядро, или где-то в khd файлах или т.п.
Более того в 4-ке и 2009 setCacheSize вообще нету...

Цитата:

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

На всякий случаай напишу версию системы и СУБД:
AX 3.0 SP5 KR2, SQL Server 2005 SP2

Кстати, в 2.5 и в 3.0 до sp3 как минимум эта цифра была не 250, а 25.

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

[abark]

Видимо стандартный алгоритм класса SystemSequence, который ведет буфер зарезервированных идентификаторов внутри AOS-а, работает следующим образом:

   AOS    getBufferSize  ,         BufferSize

Для примера для bufferSize = 250 будет такая трассировка:
1. делаем flushCache() --> N = 0 (количество неиспользованных идентификаторов), SystemSequence.NextVal = 10000000
2. первое выделение nextVal()
2.1. т.к. N = 0 < 250, то выделяем очередной блок --> N = 250, SystemSequence.NextVal = 10000250
2.2. используем первый из полученных идентификаторов, в итоге N = N-1 = 249
3. второе выделение nextVal()
3.1. т.к. N=249 < 250, то выделяем очередной блок --> N = 249 + 250 = 499, SystemSequence.NextVal = 10000500
3.2. используем очередной из полученных идентификаторов, в итоге N = N-1 = 498
4. очередное выделение nextVal()
4.1. т.к. N=498 > 250, то больше новых блоков пока не выделяем --> N = 498, SystemSequence.NextVal = 10000500
4.2. используем очередной из полученных идентификаторов, в итоге N = N-1 = 497

При нескольких AOS-ах поведение каждого отдельного AOS-а подчиняется тому же самому алгоритму.