Re[5]: CMP: ejbCreate и получение уникального Primary KEY - Java

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

J_H>Ну и? Вы просто поиграли словами и все. Так что с тем конкретным способом обойти проблемы, что изложен в указанной книге?

То что самый правильный способ обойти проблеммы связанные с EJB — не использовать EJB, пока это не потребуется. К счатью это не требуется так часто (я так понимаю единственный случай где оправдано использование EJB — это реализация true-распределенной архитекуры — то для чего они собственно и придуманы были, все остальные случаи надуманы и могут быть заменены более правильными технологиями).

L>>Кроссплатформенность на уровне серверов приложений (и уж тем более на уровне СУБД) — утопия. В большестве случаев такая кроссплатформенность не требуется. Большинство EE систем пишутся под заказ, где заказчик выложил круглую сумму денег за преобретенные АПП И БД сервера и выкладывать еще ему нету необходимости.
L>>Если пишется коробочный продукт и требуется кроссплатформенность, то достигается это все выделением непереносимого кода в отдельные интерфейсы и реализацей их для каждой требуемой платформы.

J_H>Если бы дело обстояло так, как говорите вы, то тогда никогда не возникло бы Java и J2EE, ибо этот язык и эта платформа — они просто пронизаны идеей переносимости, которая оправдывает любую сложность. Никогда не появилось бы того сонма подробнейших спецификаций, никогда не возникло бы вокруг них сообщеста, в рамках которого идет обсуждение и принимаются решения о будущем.

Хочу тебя разочаровать — дело именно так и обстоит. Переносимость бывает разная, на разных уровнях. То что дает тебе Java — это переносимость на уровне host-платформы. Как только требования к приложению выходят за рамки предоставляемых JRE севрисов — в ход идет JNI, что сразу приводит к потере переносимости на этом уровне и необходимости выделять абстакции и реализовывать их для каждой требуемой платформы.
То что дает тебе J2EE — переносимость на уровне app сервера, реализующего ту или иную спеку. Так только приложению требуется нечто большее определенного в спецификации J2EE — в ход идет тот же прием и мы опять теряем переносимость приложения и обязаны обеспечивать ее сами. И так далее, для любого уровня.

Этот же принцип работает и на J2ME платформе (только достигается другими методами).

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, 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 было глупо стандартизовывать, поскольку эта технология изначально оринетирована на поддержку источников данных самой различной природы — это производители только реляционные СУБД поддерживают, а на уровне платформы заложены более широкие возможности.

Здравствуйте, 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 аппсервер". так уж стандарт определили, и маркетинговые соображения производителей серверов подстегивают.
но для конкретного приложения маркетинговые соображения будут другими — важно не с помощью чего написано приложение, а как оно работает — быстро или нет, легко ли его расширить, удовлетворив очередной позыв заказчика, или нет.

	От:	Blazkowicz
	Дата:	18.05.05 13:18
	Оценка:

	От:	Blazkowicz
	Дата:	18.05.05 13:25
	Оценка:

От:	Lucker	http://lucker.intervelopers.com/
Дата:	18.05.05 13:42
Оценка:

	От:	John_Headlong
	Дата:	18.05.05 13:47
	Оценка:

	От:	C0s
	Дата:	18.05.05 16:56
	Оценка:	9 (2)