exppЧто мешает? Религия?
типо прикинь перфоманц будет реальный, если селекты до базы не дойдут а будут вытащены из кэша на апп.вёб-сервере.
зачем нужна трёхзвенка смотри у фаулера удачи. носи шапку
В принципе - не интересно. И в аспектах resultcache и еще сотни способов его реализации (кеша).

fynda
grexhide пишет:

> Для определения нужна конкретика.

Слово биллинг - достаточно конкретно?

Да мы коллеги, что ли? Вот тоже биллингом занимаюсь, про ява - вообще тишина (в отрасли). Ни одного применения в продакшине.

Зашедший grexhideПро то, что JavaScript это Java (клиенская часть GWT) - вот только не надо заливать. Тогда и J# - тоже, вполне себе сановская проделка.
Э? А можно этот кусок по-русски?

Забей. Лучше приведи ссылку (на какой инсайдерский блок) в котором сказано, что gmail.com обслуживается Java AppServer-ом (и каким, доступен ли он массам в т.ч.)?

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

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

Вместо того, чтобы постать откровения вроде D... г..но, ты бы лучше почитал про проблему латчей/мутексов (под нагрузкой), согласованного чтения и затрат на интерконнект (даже в крутых серверах баз данных).
-
Лучше то оно лучше. Но толко до определенного предела. Потом наступает резко плохо. А уйти нельзя - параноя-с.... все должно быть строго согласованное, версионное и непротиворечивое (ANSI SQL)

--

expp был прав. Если тыща сессий будет тупо одновременно долбиться в один и тот же блок данных (дырку памяти в случае нума-клястера), то это таки могёт быть проблемой и весьма некислой.

exppпоэтому кэш на уровне бизнеслогики завсегда отъимеет любой склсервер

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

--

вообще - не постай глупость, право. кеши - реализуются 1000-ю +1м способом на практически любой технологии, даже, блин, на голом Oracle + APEX (ты будешь смеяццо, но я запросто смогу соорудить на базе Oracle XE такие себе 1024-е сервачка, которые будут просто напросто - кешировать данные с одного клястера и раздавать на халяву контент).

И буду абсолютно чист в лицензиях и с нулевым royalty (т.е. абсолютно free).

Правда за клястер придется отстегнуть по полной программе (но это уже лирика).

-----

Хм... а это гы, блин идея.. Oracle XE RDBMS в качестве middleware к Oracle EE RDBMS.. Однако....

1024у всего есть границы. На тысячах это вполне вероятно проявится, на сотнях вероятно нет. Но любой орм будет еще более ресурсоёмкий. Что такое кеш в орм? Это объект в памяти.

Не... проблема в том, что J2EE контейнеры в общем случае тебе не нужно между собой скрещивать и постоянно синхрнизировать. Т.е. ты их можешь доставлять столько, сколько тебе нужно. Мелких, дешевых писюкофф, с персональными кешами и в целом бесплатным софтом (linux + jboss какой).

Т.е. глубоко по барабану, что они будут в 1000 раз тормознее одной сессии на оракл клястере. Зато их можно ставить много и плотно. Но как сказано выше - аж ничто не мешает масштабировать RDBMS не горизонтально, а вертикально (т.е. тупо разделять нагрузку не по нодам кластера а по отдельным инстансам с персональными мелкими базами, управляя вручную согласованностью и кешами).

Типовая задача - прайс. Прайс один, на все ноды. И чего? Да ничего, все отлично срастается. С центральной базы данных через удаленный (асинхронный) дёрг хранимки - взводятся все наружные сервера (которые не на единой СХД), эти сервера забирают себе копии прайсов, и дальше продолжают раздавать контент в штатном режиме, никого не задалбливая. В момент фиксации транзакции - отсылая данные о покупке на центральный клястер (можно и опосля это сделать).

---

Вывод - Java даже как middleware и даром не упала (правда остаётся вопрос секурности выставляения Oracle наружу... но и это решается в т.ч. (каким проксирующе-балансирующим серверком)).

В конце концов - asktom.oracle.com еще никому не удалось завалить (вроде).

exppпример№2:
optimistic locking + long time application transaction

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


Java отсосёт. В любом раскладе.

expp
номинант №1 на премию отстрели себе ноги ораклом'2007

ты как? .. сам подумал шо запостил? тебе ни кажется что чоннить добавить в такой прайс это смертельно? и некажется что несколько накладно по сравнению с hibernate+struts tutorial example. который до кластера прокачивается махом?

Ты сам сначала подумай, ок?

Объсняю схему еще раз. Мы имеем центральный многоузловой кластер (или NUMA-мейнфрейм - так даже круче).

Вокруг него натыкано куча дешевых писюков с Oracle XE. Эти писюки - раздают сессии APEX-ом, имеют полностью автономные SGA, PGA и локальные базы данных под кешами.

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

Дальше. Приходит клиент. Циска его разруливает ранудробином на какой XE сервачокс (можно и по другому рулить, но не резон), сервачокс XE сдергивает себе workplace клиента (его локальный счет и всякое разное - 1:1 как в случае J2ee) и локально его (клиента) поддерживает.

Прайсы XE сервачок тоже хранит (кэширует) в своей базе.

Все остальные запросы - дёргает по тому же самому ремотлинку (отличий - никаких, все 1:1 как и в J2EE), только с сотни раз быстрее и не через задний jdbc проход. В момент фиксации заказа - XE делает все нужные расчеты и фиксирует транзакцию на клястер (банально и тупо сбрасывает данные на СХД, клястер - нифига умного не делает, кроме блокировок и хранения раздачи данных).

-

Все. Аравидерчи. Гудбай америка, ява отстой, гослинг - хоть и класный перец, но не актуальный.

exppйопа ма SERIALIZABLE vs READ_COMMITED при том же уровне целостности. длинные транзакции чо ничо не стоят?

А какая разница что будет на той стороне ? Delphi, j2ee кАнтейнер или другой оракул?
Один хрен - клиенты. Тупые клиенты.

--

Я вот только одно не могу понять. В случае Delphi/Oracle тянуть бизнес логику на клиента - это просто детское невежество и незнание матчасти (или типа так делают только полные кретины). А в случае j2ee - все с точностью до наоборот. Ага ага.

Почему? Чем Java лучше? А? (Сидим на колокольне RDBMS клястера и рассуждаем?)

Timm
grexhideИ кто из нас теперь пи..л и клоун? А?
Ты.

Не грузи. Пойди пифка что ли попей. Или поставь пейджфайл на автосайз и открой двадцатку браузеров с JVM. И посмотри, чего там маппится в swap, а чего нет.

А лучше расскажи - ну нафига ей столько виртуальной памяти нужно сразу и много?

exppмля эт чо appserver на оракле получилсо. гы. типо на жабе оно проще и ужо есть многа.
эт ты в смысле утомилсо и свалилсо? йа думать это класс

Угум. Чистой воды middleware. Это дети вроде Леонида думают, что на Delphi можно и нужно писать что то, кроме тупого рисования мышой (хоть и продвинутого). Про использования оракла в качестве полноценного middleware я же говорил изначально (там даже ООП есть, если кому сильно неймецца).

--

И что такое на жаве есть? Давай, рассказывай, чего там такого на ценного можно соорудить, чего нельзя на PL/SQL?

Про хеши, маппинги, шмаппинги и отправку почты - не интересно. Рассматриваем тупую задачку - магазин по типу ебай.

Не, ну можно завести волынку про вепсервисы - но см. выше - городим простейший затык на EXTPROCS, который будет дергать платежи по системе VISA или PayPal, делоф то (при том этот затык поставим как раз на тот самый Oracle XE, который теперь будет делать функцию J2EE сервачка).

....

Имхо, весьма все мощно получается, и без всяких задних проходов и натужно пер... (зачернуто) рисования всякого разного в Eclipse и иже.

-------

Но про фичерсы java - расскажи (тема секса в этом направлении таки не раскрыта - крутые j2ee клястера на не менее крутых контейнерах)

vykhodtsev grexhide
И что такое на жаве есть? Давай, рассказывай, чего там такого на ценного можно соорудить, чего нельзя на PL/SQL?
Простой вопрос.
PDF нарисовать по шаблону (xml -> xsl-fo -> pdf) можно на PL/SQL?
(PL/PDF не то совсем).

Можно я отвечу один раз и кокретно? В схеме выше Oracle EE (+XE) + APEX - можно делать абсолютно все, что можно делать на java/j2ee.

А то, что нельзя - можно сделать отдельно - нарисовав простейшую EXPTPROCS или SOAP/WSDL обертку (дергая этот самый Java и т.д. - вплоть до передачи контекста сессии (правда не уверен, что это удастся передать самой яве)).

Ответ удовлетворил?

Кроме того, специально для тебя, страждущего : примерчик-с

Правда на яве я бы это делать, наверное не стал (а на кой этот гиморой? отчет в .PDF/.XML/.XLS/.DOC можно сделать и более мощными и продвинутыми средствами)

vykhodtsev
Кстати про APEX, как там с совместной разработкой и версионностью кода? (можно ли
различные ветви создавать как в SVN)?

Вот тут не уверен. Особой встроенной версионности, если честно, не заметил. Впрочем, как всегда в случае PL/SQL - экпорт/импорт кода/дампа.

По поводу более продвинутых. Не обязательно Reports, можно и в сторну даже Publisher посомтреть. Только это все слишком монстровидно, глюкаво и с душком (а... ява-индусы).

Если нужно быстро и со вкусом, то генерацию отчетов можно запросто соорудить и на сторонних внешних процессах и средствах (к примеру есть вполне адекватные PDF движки и на C/C++ (GNU и иже), и на .... хоть моветон, но все же - Delphi (хоть и придется городить тут Windows сервера, что в общем то, куда меньшее зло и куда дешевле, чем городить Oracle BI огород).

Говоря проще - это уже вопрос десятый. В рамках сессии на сервере можно дернуть RPC, а куда и как - это уже вопрос десятый. В конечном счете тебе нужно что? Файл. Просто файл.

--

PL/PDF - это действительно не то. PL/SQL - хороший язык управления данными. Но он не тянет на универсальность (пусть он будет делать что то, но хорошо, чем все, но, как правило, достаточно плохо (Java)).