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

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

А СУБД здесь почему не станет узким местом???

Кроме того, вспомним о том, что изначально этот механизм предназначен для использования как не просто генератор неких ключей, а как генератор ключей для CMP Entity Beans. То есть предполагается ИЗНАЧАЛЬНО, что приложение использует ресурсоемкие технологии в виде CMP Entity Beans. Приложения, о которых говорите вы, — это, согласитесь, спецслучай, заслуживающий спецсредств для реализации. Платформа J2EE, насколько понимаю я, никогда не позиционировалась как платформа для приложений реального времени.

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

Об оптимизации распределенных транзакций, ограниченных одним источником данных, сказано в спецификации XA, глава 2 Model and Definitions, пункт 2.3 Transaction Completetion and Recovery, подпункт 2.3.2 Protocol Optimisations на странице 8:

· Read-only
An RM can respond to the TM’s prepare request by asserting that the RM was not asked to update shared resources in this transaction branch. This response concludes the RM’s involvement in the transaction; the Phase 2 dialogue between the TM and this RM does not occur. The TM need not stably record, in its list of participating RMs, an RM that asserts a read-only role in the global transaction. However, if the RM returns the read-only optimisation before all work on the global transaction is prepared, global serialisability1 cannot be guaranteed. This is because the RM may release transaction context, such as read locks, before all application activity for that global transaction is finished.

· One-phase Commit
A TM can use one-phase commit if it knows that there is only one RM anywhere in the DTP system that is making changes to shared resources. In this optimisation, the TM makes its Phase 2 commit request without having made a Phase 1 prepare request. Since the RM decides the outcome of the transaction branch and forgets about the transaction branch before returning to the TM, there is no need for the TM to record stably these global transactions and, in some failure cases, the TM may not know the outcome.

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

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

Можете что-то более новое посоветовать, где затронут этот вопрос?

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

Вы только что рассуждали о произволительности, а вот здесь получается, что на каждую вставку необходимо два обращения в БД: одно для извлечения очередного значения ключа, второе на собственно вставку. Именно эти вопросы рассматриваются в книге, именно поэтому, например, в предложенном там решении используется сессионный фасад для Entity-компонента, предоставляющего доступ к таблице, где хранятся очередные значения ключей всех сущностей. Этот сессионный фасад огранизует кеширование блоков кодового пространства, сводя всю операцию (в ПОДАВЛЯЮЩЕМ БОЛЬШИНСТВЕ случаев) к простому инкременту счетчика в памяти.

C0s>вообще, в серьезном приложении обычно приходится использовать jms, т.к. это и удачный инструмент для событийного по своей сути программирования, балансирует нагрузку, средство интеграции и т.п. .... естественно в связке с СУБД

При чем тут JMS??? Мы рассуждаем о генерации первичных ключей для CMP Entity Beans.

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

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

А у Флойда Маринеску не надо ничего знать ни о каких диалектах, а реализовав шаблон один раз, можно использовать его везде, ничего не настраивая. Так что запарок тоже не особо много, согласны?

C0s>- аппсервер-независим

Что здесь имеется в виду? Entity Beans прекрасно стандартизованы и поддерживаются всеми уважающими себя серверами приложений. Объем специфических для контейнера настроек не велик, он касается, прежде всего, отображения на структуру источника данных (для чего есть инструментарий) и настройки специфических параметров, влияющих на производительность, например размера пулов и таймаутов. Эти настройки на уровне EJB было глупо стандартизовывать, поскольку эта технология изначально оринетирована на поддержку источников данных самой различной природы — это производители только реляционные СУБД поддерживают, а на уровне платформы заложены более широкие возможности.