Хотите просто сделать и чтобы работало - берите Томкат. Хотите потратить деньги компании и погреть на этом руки - берите WebSphere.

Vetal bI-KyЭто что, юмор такой, сравнивать промышленный сервер распределенных приложений и примитивный servlet-runner? А если нет разницы - возьмите apache с mod_ssi и наслаждайтесь динамикой.
Ну и чем отличается "промышленный сервер распределенных приложений" от "примитивного сервлет-раннера"? Тем, что "промышленный" большой, тяжелый, неповоротливый и немерянно дорогой?

Отличается тем, что цель его создания - впаривание большим "промышленным" конторам из Fortune 1000. Если повезет. А если не повезет, то впаривание прочим "промышленным" конторам.

VetalВедь и hibernate, и другие функциональности, насколько я понимаю, можно спокойно повесить на Томкат.

Или я ошибаюсь?

Нет, не ошибаетесь. Только я бы выразился иначе:
- использовать Томкат как обработчик HTTP запросов (это и только это он и делает как следует);
- использовать другие средства - такие, как Hibernate - для доступа к данным и их обработки.

Именно такой сервер работает на www.catalog-on-demand.com и вполне всех устраивает (в том числе и кое-кого из Fortune 1000 - кому надо дело делать, а не лишние деньги потратить). Рядом там, правда, стоит JBoss, ждет своего часа... но боюсь, не пригодится.

Pitbull terrierМ.Голованов, не все ведь такое черно-белое.
Думается, тысячи человеко-часов, вложенные инженерами в разработку middleware были потрачены не только для того, чтобы у маркетологов был материал для пиара.

Если Вы про WebSphere, то там "инженеры" давно уже вкладываются не столько в "разработку", сколько в копирование наработанного open source comminity... с соответствующими задержками на вникание и привинчивание. А прочее - да, работа на маркетологов... точнее, на "внедренцев".

stdioПоскольку я работаю с OracleAS, то ссылку дал на него.

Ну-ну. Вот и расскажите нам, как крутой Oracle, будучи не в силах сделать нормальный J2EE сервер, не нашел ничего лучшего, как лицензировать средненький Orion Server... со всеми его пороками, о которых мог бы порассказать...и теперь рассказывает всем про OC4J.

В смысле я мог бы порассказать - Oracle не будет. Я лично правил в исходниках один существенный пробел в реализации EJB, который делает Orion принципиально менее производительным, чем JBoss, и даже приводит к в определенных случаях к неработоспособности. Разумеется, этот пробел перекочевал в OC4J, хотя там об этом не задумываются... просто потому, что это никого не волнует. Главное - вытрясти из клиента бабки.

Vetalтам есть богатая визуальная административая среда: создание страниц, размещение портлетов, администирование. На таком уровне административного интерфейса нет ни в одном опенсорсовом портальном сервере.

так в чем же дело? Платите и езжайте. Как пассажир. А я предпочитаю сам машину водить и, что существенно, ЗНАЮ КАК. Поэтому еду куда надо. А Вы приедете куда привезут.

[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
Что у вас за манера постоянно демонстрировать снобизм?

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

stdio Именно, любой CMP Entity Bean, который он геренирует при установке приложения, будучи кэширован и хотя бы один раз обновлен в процессе своей "жизни" в кэше, при всех последующих обращениях к нему на чтение (доступ к атрибутам) до конца "жизни" в кэше исполняет ejbStore(), несмотря на то, что при последнем обновлении этот метод был уже вызван и обновления сохранены в БД
и ты считаешь, что это правильно


Я не утверждаю, что это правильно. Я утверждаю, что это неправильно. Если состояние бина было сохранено в БД после последнего обновления, то нет никакой нужды снова и снова его сохранять в БД при каждом последующем обращени к бину в других сессиях. Это противоречит концепции EJB в принципе.

ПС. Это не ответ stdio, это комментарий тем, кому интересно.