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

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

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

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

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

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

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

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

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

гарантия именно в том, что типовых способов на стороне СУБД — 2: sequences или автогенерация (инкремент или применение триггера on insert)
с точки зрения appserverа это:
— либо запрос значения ключа перед вставкой (например, выполнение select, возвращающего следующее значение sequence)
— либо запрос у СУБД получившегося в ней значения после вставки
и то и другое — не более, чем настройки, которые достаточно вынести в ejb-дескриптор
т.е. задача не такая уж большая, и производители аппсерверов беспокоятся о ее решении

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

я думаю, что СУБД, которая не поддерживает ничего для генерации уникальных ключей, вряд ли будет применима с аппсервером. потому, что в ней, думаю, еще и транзакций не будет и много еще чего.
вообще, в серьезном приложении обычно приходится использовать jms, т.к. это и удачный инструмент для событийного по своей сути программирования, балансирует нагрузку, средство интеграции и т.п. .... естественно в связке с СУБД
как следствие имеем распределенные глобальные транзакции, в которых участники должны поддерживать XA-протокол. в качестве домашнего задания могу предложить найти список СУБД, поддерживающих XA/2PC, и понять, так ли уж сильно друг от друга они отличаются в способах генерации primary key values.

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

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

это уже в поиск — на этом форуме есть отдельные нитки обсуждений hibernate vs entity ejb vs jdo и т.п.
в контексте данного вопроса упомяну лишь, что hibernate удачнее, чем паттерн Флойда Маринеску, генерирует primary key values, потому что:
— использует возможности базы напрямую без лишних слоев
— знает массу диалектов баз, и пользователю hibernate не приходится сильно напрягаться
— аппсервер-независим