[quot VetalЭтот сайт должен быть динамическим: новости, различные информационные таблицы, пользователи, которые должны видеть разный контент и т.д. Поэтому решил выбрать портальную технологию для быстрого написания и развития такого сайта.[/quot]

Вообще-то вам надо бы не спрашивать, кто что думает (потому что у всех свои проблемы и общего подхода, скорее всего, нет).

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

Помимо осмысленного выбора, будете также иметь и отмазку от начальства. Одно дело слова, другое - документ.

Спасибо А.Грасоff™ за исчерпывающие комментарии. Если то, что я утверждаю, спорно - утверждайте обратное. Люди прочитают и сделают выводы.

Кроме того, здесь собрались специалисты, которым важнее факты, чем утверждения. Действительно, мое утверждение о том, что коммерческие продукты делаются прежде всего в расчете на "продаваемость" (в том числе - чего уж скрывать, в схемах отмывания ИТ бюджетов - Оракл в этом деле в России постоянно светится) и часто в ущерб качеству, всего лишь утверждение. Приведу факт.

Не далее как в конце 2004 года, тестируя одну навороченную систему онлайнового резервирования на Orion Server, обнаружили мы под реальной нагрузкой многочисленные немотивированные блокировки транзакций. Сделав JDBC trace и сопоставив ее с кодом, я обнаружил, что Орион делает одну неприятную и явно лишнюю вещь, которую по спецификации и духу EJB он делать не должен. Именно, любой CMP Entity Bean, который он геренирует при установке приложения, будучи кэширован и хотя бы один раз обновлен в процессе своей "жизни" в кэше, при всех последующих обращениях к нему на чтение (доступ к атрибутам) до конца "жизни" в кэше исполняет ejbStore(), несмотря на то, что при последнем обновлении этот метод был уже вызван и обновления сохранены в БД.

Как сами понимаете, постоянный вызов ejbStore() и соответствующий UPDATE при определенных настройках предполагают блокировки БД, которые и приводят к блокировкам транзакций (deadlocks) там, где их никто не ждал. Программист-то в этих транзакциях обращался к Entity Bean на чтение и совершенно обоснованно строил транзакцию в расчете на то, что эти бины будут или читаться из БД (если их еще нет в кэше), или просто браться из кэша без каких-либо обращений к БД.

Причина оказалась проста: при выполнении ejbStore() не сбрасывался флаг dirty. Флаг продолжал торчать со всеми вытекающими последствиями до конца жизни любого такого Entity Bean.

Понятно, что это грубая ошибка в реализации основополагающего принципа EJB. В EverMind, однако, мои просьбы прокомментирвать этот факт были проигнорированы, и Orion Server до сих пор выходит с этой ошибкой. Я же декомпилировал соответствующий класс, исправил код и пересобрал orion.jar. После этого блокировки пропали и производительность (за счет исключения явно лишних UPDATE) заметно выросла. Что совершенно понятно - для того EJB и придуманы.

Не далее, как в 2005 году, пришлось мне работать с OC4J, и я, зная, что по существу он - не что иное, как лицензированный Orion server, для интереса решил посмотреть, присутствует ли в нем эта беда. Оказалось, присутствует во всей красе. Со всеми вытекающими послествиями в производительности и потенциальной опасности немотивированных блокировок (deadlocks).

Так что можно много рассказывать о наворотах, но если ядро продукта грешит такими ошибками, навороты это вряд ли компенсируют. Да и продавцам легче (да и выгоднее) предложить клиенту поставить кластер там, где при исправлении ошибки справилась бы одна машина. А что касается опубликованных сравнительных тестов, то там цифры тем лучше, чем больше за них заплачено.

Для сравнения, в JBoss (по крайней мере с версии 3) я таких грубых ошибок не наблюдал.

stdioА если в БД я ручкам после последнего ejbStore() выполнил UPDATE через SQL*Plus и таким образом рассинхронизировал состояние компонента и данные постоянства? Не для этого ли ejbStore() вызывается перед чтением атрибута компонента?

Нет, не от этого. Внимательно читайте спецификации и то, что я пишу.

1. Если есть основания ожидать, что Entity Bean может рассинхронизироваться вследствие обновления записи вне EJB контейнера, есть возможность при установке (deployment) указать exclusive-write-access="false".

2. Но даже при этом бин будет ПЕРЕЧИТЫВАТЬСЯ, а не ОБНОВЛЯТЬ запись в БД. Это две большие разницы, как известно. В том числе и с точки зрения блокировок в БД.

stdioПрисылай тесткейс в саппорт, заведём баг, сообщим, когда будет исправлен.

А мне это надо? В лучшем случае это проблемы моих заказчиков, которые используют Оракл. А deadlocks, если знаешь что делаешь, можно избежать.

Pitbull terrier М.Голованов off
Что у вас за манера постоянно демонстрировать снобизм?

Неужели так заметно?... или просто кажется? Возможно, я просто знаю себе цену, а это обычно раздражает.