Hibernate: Hi/Lo алгоритм генерации идентификаторов

Hi/Lo алгоритм генерации идентификаторов предполагает следующее: чтобы за каждым идентификатором нового persistent-объекта не бегать в БД (как в случае с, например, sequence-генераторами), можно "резервировать" сразу некоторое количество идентификаторов, и назначать их новым объектам, пока они не закончатся и не придется снова идти в БД за новой партией. 

Резервирование заключается в следующем: идентификатор разбивается на 2 части (например, поразрядно). Первая часть (n старших разрядов) - "hi", берется из БД (например, из последовательности). Вторая же - "lo" (m младших разрядов), последовательно назначается приложением. Размер m настраивается в конфигурации, n же определяется типом данных (short / int / long) и установленным размером m.

Пусть, например, m равен двум десятичным разрядам. Тогда, в начале, приложение запрашивает очередное hi-значение из БД (например, из последовательности), и затем использует его для генерации 100 идентификаторов для новых объектов. Скажем, если полученное значение последовательности равно 17, то диапазон идентификаторов, который сможет использовать приложение для новых объектов, будет равен [1700,1799].

Особенно данная оптимизация эффективна при выполнении пакетных вставок большого числа записей в БД.

PS Правда, генератор seqhilo в Hibernate 4.1 ведет себя немного отличным образом: для приведенного выше пример он генерирует последовательности идентификаторов: [1717, 1816], [1818, 1917] и т.п., т.е. он сначала прибавляет hi-значение к младшим разрядам, и лишь потом начинает инкрементирование. Это приводит к образованию не сплошной последовательности идентификаторов, а hi- и lo-части делятся уже не поразрядно. Возможно, такому поведению есть какое-то объяснение, нужно поискать.