> К примеру, почему не популярны хостинги простых JSP-приложений, по функциональности сопоставимых с LAMP? Ведь для JSP не нужен весь стэк JEE-библиотек и разворачивается оно легко и непринуждённо (кстати, без Apache можно обойтись — одним лишь Tomcat); опять же, заявлена кластеризация и балансировка нагрузки.

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

>Можно-же делать 100-%-параллельный кластер как гугле и пр. И заранее знать - сколько тебе машинок надо еще на столько-то миллионов юзеров.

Можно, конечно. Еще раз, сравни уровень разработчиков архитектуры Гугла и разработчиков на J2EE в средней руки банке. И скажи, как в этот банк из Гугла заманить специалистов? Платить им $200000-250000/year? Больше, чем гендиректору банка?

Лор работает, периодически вываливая ошибки и вешаясь.

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

Впрочем, как бы ни была плоха жаба, переплюнуть ASP ей не суждено. На asp лор был бы не полузомби, а зомби.

>А еще можно сравнить ЛОР и РСДН, например, у которого постоянно не работает то поиск, то форум, то и то и другое (я уже не говорю об удобстве использования).

RSDN ГОРАЗДО удобнее в использовании. CSS и стиль грамотнее, ветки можно читать простыней (для печати), видно, кто на чье сообщение ответил и т.п. И у них в отличие от LOR, есть оффлайн клиент с возможностью складывать сообщения в БД, а не убогий tkLOR, который на венде не может запуститься изкаропки. ХЗ что ему нужно искать и доустанавливать

А поиск не работает на ixbt.com который на кошерном Perl написан

А еще Академия Наук подписалась за 4 миллиарда руб. сделать аналог JBoss для нужд МВД. Ну, для интеграции десятков баз и учетов в Единое Информационное Пространство. Ведь изобретут в итоге свою собственную жабу и клонируют всю функциональность готовых Java AS. Только за 4000000000 руб. Хороший контракт?

> RSDN ГОРАЗДО удобнее в использовании.

Сколько евреев, столько мнений. Лично мое: если и возможно написать что-то более неудобное и глючное, чем РСДН, то это будет очень непросто.

> убогий tkLOR, который на венде не может запуститься изкаропки

linux.org.ru: проблемы алтернативных ОС -- это проблемы альтернативных ОС.

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

Про формат файла даже не слышали. Путают с расширением файла.

csv файл с расширением *.txt у них называется текстовым форматом, а с расширением xls - файлом в формате ексель.

Сколько я не видел работников ява-отделов, ни одного компетентного не попадалось, хуже были только 1-с программисты. Те вообще животные...

> Лор работает, периодически вываливая ошибки и вешаясь.

Скажем так: это бывает нечасто и мне, как активному посетителю это не мешает, в отличии от того же рсдн.

У eBay middle-tier на Java сделан. Работает же. И нагрузка у него будь здоров. Впрочем, JEE они там практически весь выкинули, что вполне разумно.

>Ты поищи портал сравнимый с ibm.com по размерам.

http://www.akamai.com

> Ну нарисуй вебсервисы на коленке.

легко,
http://techbase.kde.org/Projects/D-Bus-WS

на питоне сойдёт? http://websvn.kde.org/trunk/playground/libs/webtech/dbus-ws/examples/

>нету ее, неограниченной калабилити-то, при общей транзакционности...

http://www.gigaspaces.com/migration

>А профессионалы это делали и до жавы и 15 и 25 лет назад и очень просто и надёжно - путём логов (то как это базы реализуют).

Путем логов, ага. А если количество транзакций вырастет в 1000 раз, лог справится? А лог ведется за день, за час или как? А дисковая подсистема не упарится бегать по гигабайтному логу, проверяя, завершились ли предыдущие транзакции? А ACID в логе поддерживается?

Вон, люди проверяли, как FreeBSD 16процессорность поддерживает http://forum.ixbt.com/topic.cgi?id=5:13-72#2570 И всё еще порываются переписать форум не на ASP.NET или J2EE, а на PHP. Я уже сижу с попкорном, PHP на FreeBSD 7.0 это будет смешно

> Потому что жабимй веб-хостинг будет постоянно лежать.

Это оригинальные исследования или есть какая-то база?

>Это оригинальные исследования или есть какая-то база?

Знания, подкрепленные долгим и мучительным опытом.

>Знания, подкрепленные долгим и мучительным опытом.

Может, тогда стоит сменить профессию?

Прежде чем рассказывать про Долину, сперва поичтай стандарты, документацию и попробуй в работе.

Порядка 90% программеров знать не знают что есть такая вещь как "администрирование" и что такое telnet. Ты вот, к примеру, не знаешь стадарты JEE. Изучи обе области, тогда появится желание не сравнивать, а совместно использовать.

> а про веб сферу можно сказать что ко всему прочему она ещё и более тормознутая и сложнее конфигурируемая чем jboss.

А вы, простите, что собираетесь крутить на очень_больших задачах? Apache Tomcat? Ага, особенно на мейнфреймах IBM z/series :)

>А вы, простите, что собираетесь крутить на очень_больших задачах? Apache Tomcat?

Почему бы и нет. Опять же, AFAIK, eBay крутит свой middle tier на подкрученном Tomcat-е.

Впрочем, непонятно, что имеется ввиду под очень_большими задачами? Большая нагрузка, сложные транзакции, покрывающие несколько ресурсов, массивные вычисления или что-то иное?

> Опять же, AFAIK, eBay крутит свой middle tier на подкрученном Tomcat-е.

Блин, еще один теоретик-первооткрыватель. Первый раз приводил r, яприведу второй раз:

http://highscalability.com/ebay-architecture # Platform

# Java # Oracle # WebSphere, servlets # Horizontal Scaling # Sharding # Mix of Windows and Unix

>Блин, еще один теоретик-первооткрыватель. Первый раз приводил r, яприведу второй раз:

Значит, они переделали. Пару лет назад там точно был Tomcat.

> Как быть с однородными Web-технологиями? К примеру, почему не популярны хостинги простых JSP-приложений, по функциональности сопоставимых с LAMP? Ведь для JSP не нужен весь стэк JEE-библиотек и разворачивается оно легко и непринуждённо (кстати, без Apache можно обойтись — одним лишь Tomcat); опять же, заявлена кластеризация и балансировка нагрузки. Для PHP: обязательно наличие Apache Server, подключаемого модуля интерпретатора, плюс разные настройки и конфигурация для того и другого, плюс программные фреймворки и библиотеки, заточенные под определённые задачи. Тем не менее, PHP популярнее JSP в десятки раз (если кто из пользователей вообще слышал о JSP).

Ответ, на самом деле, очень прост: стоимость. Причём, в случае обычного хостинга (который или shared, или, в крайнем случае, PVC на виртуоззе или аналогичной технологии "лёгкой виртуализации") к стоимости разработки (а программисты на PHP стоят дешевле программистов на яве) добавляется стоимость организации хостинга и т.н. денсити, то есть, плотности виртуальных машинок или хостов на одной физической железке. И вот по параметрам ресурсожручести томкат проигрывает LAMP'у просто катастрофически.

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

К тому же, стек готовых бесплатных пыхапэшных приблуд "разверни-меня-из-архива-и-пропиши-адрес-зады-банных" довольно велик и, как следствие, нет необходимости напрягаться ;-)

> добавляется стоимость организации хостинга и т.н. денсити, то есть, плотности виртуальных машинок или хостов на одной физической железке. И вот по параметрам ресурсожручести томкат проигрывает LAMP'у просто катастрофически.

Стоит отметить, что это справедливо только для "отдельных" пользовательских приложений, и не относится к интегрированным сервисам, ради которых всё это затевается. Просто разные задачи и разные способы их решения. Я вполне могу представить хостинг, к примеру, JBoss Portal, в котором покупается не учётка на хостинге, а учётка в JBoss.

>А почему распределенную транзакцию должен делать *комбайн* типа JBoss?

>Почему нельзя иметь SQL сервер, интергрирующий доступ к несколькми СУБД и умеющий распределенные транзакции?

Потому что дорого. Тебя с таким решением в банк даже на работу не возьмут. SQL СУБД, интегрирующие доступ к нескольким СУБД, бывают только Enterprise, Oracle Enterprise, DB2 Enterprise и MS SQL Enterprise. Всё. Цены сам найдешь? И если вся прибыль банка за год будет уходить на оплату лицензий за эти СУБД. Сам дальше поймешь? А JBoss из коробки бесплатный.

Re^2: Вышел JBoss 5.0.0

> Да, в крупных компаниях. Пока ты будешь месяц писать прогу на C/PHP, которая из базы данных по телнету отдавать данные, люди десятком кликов мышкой в VisualStudio за 20 минут сделают то же самое.


Ох, бл... Где-то год назад пришел чувак к нам в контору, говорит навояли они словарик на C# и хотят к нему веб-морду на PHP (дают WSDL типа). Ну, думаю, ничего сложного. Далее он говорит, что он уже обошел почти все пхп-конторы что видел и никто не смог сделать. Я с подозрением, но всё равно был склонен к тому, что это пхпшники ему попались необразованные.

Оказалось что эта идиотская Visual Studio умудрилась сгенерировать WSDL (который определён в w3c-стандартах) криво и не по стандартам. Более того, сама студия своё г. прекрасно понимала.

Так что ваши десятки кликов можете превратить в многочисленные письма разработчикам с умолениями об исправлении. А потом идти учить C.

> Оказалось что эта идиотская Visual Studio умудрилась сгенерировать WSDL (который определён в w3c-стандартах) криво и не по стандартам. Более того, сама студия своё г. прекрасно понимала.

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

>Оказалось что эта идиотская Visual Studio умудрилась сгенерировать WSDL (который определён в w3c-стандартах) криво и не по стандартам. Более того, сама студия своё г. прекрасно понимала.

Когда-то давно сталкивался с сервисом, в котором по-простому датасет .NET-ный через SOAP сервис выставили. Так там в WSDL, в схеме, просто <xsd:any /> было на месте датасета. Как хочешь, так и выковыривай данные.

Естественно, .NET-ный клиент «знал», что там на самом деле датасет и правильно его восстанавливал.

> Так там в WSDL, в схеме, просто <xsd:any /> было на месте датасета. Как хочешь, так и выковыривай данные.

на rsdn пару лет назад было точно так же... это диагноз :)

>Я уже сижу с попкорном, PHP на FreeBSD 7.0 это будет смешно

FreeBSD даже без всякого PHP это уже смешно

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

А ведь самое хреновое, что под этим маркетинговым слэнгом лежат простые и обыденные понятия.

Может тут действует принцип "Разделяй и властвуй", маркетинговый слэнг заменяя обыденные слова, приводит человека к мысли что кроме жабки использовать в энтерпрайзе ничего нельзя.

Плюсом к этому идут мифы что, xml(soap wsdl), распределенные транзакции, балансировка нагрузки, ничем кроме жабки сделать нельзя.

Да умойтесь, это все можно сделать на чем угодно, и порой даже более эффективно.

>если надо интегрировать много баз - лучше написать SP или триггер, т.е. свести всё как у меня - к одной базе.

Это невозможно. Сюрприз? Есть у больших систем такое свойство "непеределываемость за неделю".

>. Сколько одновременно юзеров вы обслуживаете - 10 максимум?

Для тебя сюрприз что есть различные уровни транзизоляции, и что транзакция на других источниках подключается не одновременно, а по ходу, и что есть базы данных-версионники?

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

Я тебе предложил задачу с N транзакционных ресурсов - не надо объяснять про то надо или не надо удалять файлы.

>Временные таблички могут помочь также

Боже какую чушь ты несешь. Какие временные таблички. В очередной раз спрашиваю - ты что решаешь задачу предполагая что твои временные таблички бессбойное хранилище с безоткатной логикой? В таком случае вообще никакие транзакции не нужны если нет данных которые нужно изолировать. Ты что не понимаешь что то что ты предлагаешь это частный случай не имеющий к транзакциям никакого отношения?

>А что случилось с SOAP::Transport::HTTP::Apache всякими? Совсем не работают?

Ага то есть нужен каменный цветок?

>Кстати год назад говорили, что потроха SimpleDB -- на Erlang.

Дело не в языке а в нужности или не нужности OASIS-вебсервисов. Вон для кого-то и новостная лента лора - вебсервис.

>Почему нельзя иметь SQL сервер, интергрирующий доступ к несколькми СУБД и умеющий распределенные транзакции?

НАверное потому что логику тогда надо будет писать в этом sql сервере - что совсем несмешно?

>Далее морду можно написать на любом языке.

ТЫ когда нить видел большие системы описанные с логикой в тригенррах? Вот где ужос - когда для того чтобы записать файл на диск пишут триггер.

>Я тебя не понял, выскажись поподробней.

Транзакционным ресурсом может быть не только база - чтоя предложил в задачке для ума - в данном сдлучае месседжинг тоже транзакционный. Записать в базу и отправить месседж как атомарная операция.

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

>А ЛОР вот простенький, убогий, где-то не очень удобный, и смотри ка подлец, работает и не жужжит :)

А еще он на быдложабе. А не на пэхэпэ.

>http://www.akamai.com

Вижу ммаленький корпоративный сайт.

> легко,

Не легко а через стандарты оазиса - ЧИТД.

>на rsdn пару лет назад было точно так же... это диагноз :)

Вообще-то это то Extend из 3e микрософта. ТАм где .NET с .NET дружиться а не с .NET не очень - потому что ганяет даные которые WSDL не описаны. ЗА это надой яца разрабам отрывать.

>Да умойтесь, это все можно сделать на чем угодно, и порой даже более эффективно.

Все можно написать хоть на ассемблере.

>Транзакционным ресурсом может быть не только база - чтоя предложил в задачке для ума - в данном сдлучае месседжинг тоже транзакционный. Записать в базу и отправить месседж как атомарная операция.

категорически не согласен - что всё пихаешь в транзакцию. Это примерно такой-же подход как и локать всё (вместо того чтобы думать - что же действительно должно удовлетворять ACID'ity) - вместо локанья минимального дебит-кредита, что порой единственное - что должно быть транзакцией. Остальные вещи (и уж тем более месседжинг) - уж никак не в транзакции. И мы удивляемся что всё так тормозит? "что такое мультизадачность, папа Билл? подожди, сейчас дискетку отформатирую"(С). Флоу сервлета или процесс CGI - уже изолированный контекст (может вы и сиквенсы в тразакции генерируете?;) Это виндузячий подход - если не знаешь как работает, но надо тред-сейфти - локать всё по-максимуму (презерватив на свечку). Транзакционные изоляционные уровни - вообще в компетенции дба (вспомним насколько по-разному локает оракле и дб2) и вы, жаба-программисты с таким подходом - обычно делаете всё сериализованным через жаба-транзакционные аттрибуты ("как-бы чего не вышло"). Как говорилось выше - самые успешные проекты в моей практике были там - где _DB-девелоперы_ писали хранимые процедуры- как АПИ к базе, а жаба-девелоперы - пользовались этим АПИ (где каждый вызов - атомарный), не лазя в области где они не контролируют ситуацию, и не лезли в транзакции. ДБ тюнинг, переделка схемы, денормализация - должны быть в компетенции дб-программистов (кто пишет хранимые процедуры), а не жаба-девелоперов, которые пишут морду.

> оазиса

Посмотри на спонсоров этого оазиса, на которого ты молишься. И подумай - зачем им надо пропихивать это говно.

хмл, соап,... Дальше можно не читать.

>Остальные вещи (и уж тем более месседжинг) - уж никак не в транзакции.

Почему это? Тебе пришло сообщение «списать со счета». Нужно атомарно сделать два действия: пометить сообщение, как обработанное, и списать со счета в БД.

Конечно, в простом случае, если у нас сообщения в той же БД, эта задача решается чисто локальными транзакциями.

>жаба-программисты с таким подходом - обычно делаете всё сериализованным через жаба-транзакционные аттрибуты

Ну, это не всегда возможно. Как известно, в Oracle нет настоящего SERIALIZABLE. :)

> категорически не согласен - что всё пихаешь в транзакцию

Транзакция в данном случае - ACID операция. От того что ты с чем-то категорически несогласен не от меняет того что оно так и есть и это требование.

>Транзакционные изоляционные уровни - вообще в компетенции дба

Хрена с два. Это как раз всегда в компетенции конкретной логики.

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

> Посмотри на спонсоров этого оазиса, на которого ты молишься. И подумай - зачем им надо пропихивать это говно.

Посмотри на спонсоров любой стандартизирующей организации.

>Дальше можно не читать.

Продолжай ваять на пхп форумы и не парься.

> ТЫ когда нить видел большие системы описанные с логикой в тригенррах? Вот где ужос - когда для того чтобы записать файл на диск пишут триггер.

я видел. Много триггеров - плохо. Но твоё решение - хуже (больший лок - аж из жавы, через сетку и пр.). Ты тоже локаешь базу и когда юзеров много - будет очень больно. Чем ниже лок - тем лучше. И хранимая процедура - гораздо ближе к базе - чем жаба-процесс, ползущий на удалённой машине.
Потом триггер может вызвать ехек кода и тот код - сделает всё что надо (я делал это в оракле). Это если уж никак нельзя не в одной транзакции. Хотя бьюсь оз заклад - это плохой дизайн - если транзакция - больше чем дебит-кредит (программеры поленились проанализировать состояния, написать немного больше чистящего кода, и локают всё - решая всё транзакциями).

>. Но твоё решение - хуже (больший лок - аж из жавы, через сетку и пр.).

Лок ты сам придумал - нет никакого лока повторяю.

>Ты тоже локаешь базу и когда юзеров много - будет очень больно.

Повторяю четвертый раз _никто ничего не локает_.

>И хранимая процедура - гораздо ближе к базе - чем жаба-процесс, ползущий на удалённой машине.

Вот где звездец начнется - это когда хранимые процедуры пишут файлы - ибо там действительно начинается блокировка в базе.

В моем решении правильный ордеринг все решает - сначала файл, _потом_ _присоединяется_ транзакция в базе, потом _присоединяется_ транзакция в биллинге - атомарный коммит и все. Никаких локов нет. А вот триггер у тебя должен быть включен в уже начавшуюся транакцию в базе. Мое решение по скорости сделает все твои тригера вместе взятые.

База - это один из боттлнеков сам по себе. Что-то щатормозить больше чем реляционная база - это надо умудриться. А ты и так в самый тормознутый элемент еще больше логики напихал.

>Потом триггер может вызвать ехек кода и тот код - сделает всё что надо (я делал это в оракле).

Мля двадцйатый раз повторяю - как ты твой экзек откатывать будешь? Никак? Не можешь решить задачу - так и скажи хватит мозг парить.

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

мой ответ: они _не должны_ быть в одной транзакции. Если слетает операция - просто не посылаем сообщение. Если слетает машина (между этими 2 операциями) - для этого я обьяснял про состояния (при перезагрузке - первым делом - проверяется - нет-ли не отосланных сообщений). можно сделать ещё проверки.
Но моё решение - намного более гранулированное, эффективное и масштабируемое, чем всё локать. Я ответил.

>. Если слетает операция - просто не посылаем сообщение.

Это пять балов - ты по сути вообще не понимаешь что такое транзакция. Обясню на пальцах: есть две операции A и B и они должны быть выполнены или обе или ни одной. Слететь может _любая_. Доступно? Читать определение ACID до прозрения.

>Я ответил.

Вот что ты ответил - ты сделал комит в базу и если он прошел - послал мессадж. Если мессадж не прошел - ты в торбе - в базе данных комит и паралелльные системы это уже увидели - состояние неоткатываемо в общем случае безотносительно всяких там undu которые ты напишешь.