S>Ага, ясно, благодарю. Собственно, я на хабре нашел статью, где обсуждался этот механизм, и там соотв. таблица
S>(sequence) генерится EF на уровне бд. Соотв. вопрос -- значит при создании контекста бд\сессии он, вновь
S>созданный контекст, будет неявно ходить в бд для получения нужной последовательности? Иначе как мы узнаем hilo?

Ну да. Контекст ходит в БД для получения текущего значения sequence (или текущего Hi-значения в случае HiLo).
Смысл в том, что он ходит раз в N (e.g. 10-100) вставок, а не каждый раз.

S>Кстати, не факт -- получить мы получили, но может быть проблема сохранить все это в бд. Таким образом
S>у нас появляется неконсистентность -- типа пишем, что есть ид от бд, хотя его в реальности еще нету.
S>Ну т.е. при попытке сохранить данные может что-то пойти не так.

Ну и что? В логах ты это увидишь примерно такое:

[Info] Order #100 created
[Info] Order item #101 for Order #100 added
[Info] Order item #102 for Order #100 added
[Info] Saving order #100 to DB
[Error] Db unavailable exception

Смотришь лог. Понимаешь, что БД была недоступна, записи по факту не вставились. Ну бывает, чо.
Это ничем не отличается от случая, если бы вместо int'овых Id ты использовал, скажем, Guid.

> А что это такое? Типа общий, уникальный id для всех объектов в бд?
Да. Для аудита такое иногда просят: чтобы любой объект в БД глобально-уникально идентифицировался по Id.