Здравствуйте, C0s, Вы писали:

C0s>беда — в неэффективности генерации ключей без прямого использования поддержки со стороны СУБД (потери на задействовании нескольких уровней выше СУБД, хотя задача изначально на уровне СУБД уже, как правило, решена — либо в виде sequenses, либо в виде auto-increment)
C0s>т.е. в ситуации, когда таблица заполняется по факту ручной работы сравнительно небольшого количества операторов-пользователей программы, это еще терпимо, а если например, надо обрабатывать и логировать сообщения, поступающие с высокой плотностью, то этот генератор станет узким местом

Ну почему же этот способ неэффективен? Как раз в решении, описанном в книге, очень много внимания уделяется именно эффективности реализации механизма. Там ведь не тупой инкремент счетчика, который хранится в БД, а организовано кеширование диапазонов значений ключей, чтобы в подавляющем числе случаев генерация ключа сводилась к инкременту числа в памяти. Автор позаботился даже о тонкой расстановке транзакционных атрибутов, чтобы при массированном использовании механизма это не приводило к длительной блокировке конкурирующих транзакций. Поясните, пожалуйста, в чем вы видите неэффективность?

C0s>сам пример в указанной, imho, больше содержит учебной информации для размышления, нежели применим на практике в серьезных приложениях

А мне казалось, что книга под названием EJB Design Patterns предлагает решения распространенных практических проблем для использования как раз именно в серьезных приложениях. А что бы вы посоветовали почитать на затронутую тему?

C0s>большинство СУБД имеет либо sequences, либо auto-increment. также в некоторых (для меня — экхотических) случаях применяются триггеры
C0s>зная об этом, ведущие производители контейнеров эти случаи уже так или иначе закрыли, для применения достаточно разбираться в конкретных форматах вендор-зависимых частей ejb-дескрипторов
C0s>так или иначе, а разработчики программы страдают меньше всех — потому что дескриптор настраивает DEPLOYER

Это понятно, но где гарантия, что при переносе решения с одного сервера приложений на другой сервер приложений или при подмене одной СУБД другой СУБД не возникнет проблем? Средства генерации первичных ключей и все тонкости, что с ними связаны, практически не стандартизованы, здесь каждый производитель СУБД считает своим долгом отличиться, проявив тем самым свою "уникальность" на рынке. В случае возникновения таких проблем это уже затронет и разработчиков, а не только deployer'а. Приятность же кроссплатформенного решения как раз и состоит в том, что это гарантированный результат в любой конфигурации, разве нет? Причем эта кроссплатформенность как на уровне серверов приложений, так и на уровне СУБД. Причем последняя может вовсе не поддерживать никаких средств генерации уникальных ключей.

C0s>но мне больше нравится подход hibernate — мы его используем вместо entity ejb. там есть несколько разных генераторов первичных ключей, в т.ч. поддержка sequences, auto-inc, а также поддержка автовыбора одного из этих 2х наиболее популярных способов в зависимости от используемой СУБД.
C0s>настройки же делаются исключительно в xml hibernate-мэппингов без нагрузки на исходный текст программы

Лично я не совсем понимаю преимущества использования каких-то сторонних решений o/r mapping в серверных приложениях вместо стандартного средства — Entity Beans. В чем они? Клиентские приложения — это совсем другое дело.