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

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

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

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

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

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

звучит как "мы вот здесь выбрали ресурсоемкое решение задачи, поэтому совершенно оправданно сопутствующие ей дополнительные задачи также решить ресурсоемко"

кстати, я не говорил о реальном времени — откуда это? я всего лишь привел пример задачи, которая по требованиям (плотность потока=x) решается кластеризацией с вычисленным количеством узлов n(x). если генератор значений придется доводить до кластеризуемого состояния (а у Маринеску, насколько я помню, он не кластеризуемый), то невелика цена этому генератору.
при этом я хочу заметить, что я просто выбрал некий граничный вид задачи, чтобы лучше показать слабости и без того непростого подхода, как custom-решение уже решенной задачи.

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

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

J_H>· Read-only
J_H>· One-phase Commit

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

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

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

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

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

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

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

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

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

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

все-таки 'cmp entity beans' — подсознательно я полагаю, что это признак серьезного приложения. т.е. приложение строится с использованием ejb. так и быть, оставим jms в стороне, но напомню, что есть mdb — такой вид ejb. и наверняка его тоже придется использовать. и тогда список подходящих СУБД все равно будет сокращен.
можно, конечно, и проще сказать — заказчик серьезного приложения обычно будет заботиться, чтобы использовалась приличная СУБД...

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

в моем опыте и опыте других посетителей этого форума — это, прежде всего, большие возможности. например, когда возникает необходимость эффективной выборки части данных из нескольких таблиц, cmp курит в сторонке, а hibernate щелкает как орешки
т.е. можно сказать, что все идет от задач. мои задачи с помощью hibernate я решаю так, как мне нравится. когда я аналогичные задачи пытался решать с помощью cmp ejb, то либо они не поддавались нормальному решению, либо решались так, как меня не устраивало (лишние селекты вместо joinа, отсутствие возможности внятно ограничить список выбираемых полей и т.п.).

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

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

мне с hibernate тоже не надо знать о деталях диалектов, достаточно помнить об их существовании

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

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

в реальном приложении приходится использовать много сторонних библиотек (commons-*, например), одной больше — другой меньше, на сложность деплоймента это не влияет. я имею в виду, что если задеплоить на новый аппсервер приложение, использующее hibernate, будет проблемой, то эта проблема — рук и/или аппсервера. для нормальных аппсерверов проблемы быть не должно

кстати, насчет "Entity Beans прекрасно стандартизованы и поддерживаются всеми уважающими себя серверами приложений": ejb в полном объеме (т.е. с entity beans) приходится поддерживать, прежде всего, для шильдика "J2EE1.3-fully compatible аппсервер". так уж стандарт определили, и маркетинговые соображения производителей серверов подстегивают.
но для конкретного приложения маркетинговые соображения будут другими — важно не с помощью чего написано приложение, а как оно работает — быстро или нет, легко ли его расширить, удовлетворив очередной позыв заказчика, или нет.