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

B>Здравствуйте, denis.zhdanov, Вы писали:

DZ>>здесь
B>И JBoss treecache, эти двое на пару вроде бы самые перспективные.

А у меня вот сходу ещё такой возник вопрос:
Я на сколько понял и treecache & terracota это распределённые кеши ?

Я когда говорил о кластеризации имел в виду паралельное испольнение скажем, SLSB на кластерах, или просто
многопроцессорной машине ?

Известны какие то варианты как добится того же от spring'а ?

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

ёё>А у меня вот сходу ещё такой возник вопрос:
ёё>Я на сколько понял и treecache & terracota это распределённые кеши ?
terracota даже нечто большее.

ёё>Я когда говорил о кластеризации имел в виду паралельное испольнение скажем, SLSB на кластерах, или просто
ёё>многопроцессорной машине ?
Эээ, с многопроцессоными вопроса не понял. А в чем сложность-то? Запускаешь аппликуху на двух нодах, вот бины и работают параллельно. В чем суть вопроса?

ёё>А то и вообще spring+...orm ?(я к сожалению не знаю можно ли spring привязать к jpa, руками их не щупал )
Можно. Только JPA довольно простенькое API — сильно не хватает, например, хибернейтовских критериев

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

B>Эээ, с многопроцессоными вопроса не понял. А в чем сложность-то? Запускаешь аппликуху на двух нодах, вот бины и работают параллельно. В чем суть вопроса?

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

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

А в случае спринг приложения наверно придётся делать каике-то хитрые движухи, если их
вообще можно зделать ? и какие ?

В случае кластеров ejb приложение будет пооддерживать распределённые транзакции между этими кластерами.
Я не знаю сможет ли их поддерживать terracota, раз уж это нечто более, чем распределённый кеш ?
может какие то другие фреймворки ?

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

ёё>я где-то, когда-то читал, что приложение написаное в соответствии с ejb и исполняющееся в ejb контейнере
ёё>может свободно, без лишних усилий работать в многопоточной среде.
Сервлеты тоже свободно без лишнизх усилий работают в многопоточной среде. Это никак не заслуга EJB.

ёё>вопрос про многопроцессоры он сосбтвенно про то и был,
ёё>если у нас одна машина, на которой 4 процессора.
ёё>То по идее если развернуть на машине ejb приложение, оно будет исполнятся там оптимально
ёё>используя мультитрединг.
Это все сугубо упирается в реализацию JVM и операционную систему. К EJB обратно никакого отношения не имеет.


ёё>А в случае спринг приложения наверно придётся делать каике-то хитрые движухи, если их
ёё>вообще можно зделать ? и какие ?
Эка у вас фантазия богатая. Хитрая движуха это случайно не new Thread().start()?

ёё>В случае кластеров ejb приложение будет пооддерживать распределённые транзакции между этими кластерами.
Менеджер распределенных транзакций прикручивается к Spring без проблема. Менеджер, поставляется вендором сервера приложений.

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

B>Сервлеты тоже свободно без лишнизх усилий работают в многопоточной среде. Это никак не заслуга EJB.
Да сервлеты работают без лишних усилий потому что у них есть среда (сервлет контейнер) которая поддерживает для них многопоточность.

B>Это все сугубо упирается в реализацию JVM и операционную систему. К EJB обратно никакого отношения не имеет.
Мне казалось что ejb предоставляет подобную среду своим компонентам, и я как-то не думал, некогда, что это может упираться в JVM & OS.
Да возможно в случае однозадочной OS например =)) это очевидно...
Но в иных случаях...
Ты не мог бы если не лень пояснить на примерах ?

B>Эка у вас фантазия богатая. Хитрая движуха это случайно не new Thread().start()?
В самом простом случае да...
Собственно наверное что-то похожее работает и в сервлет контейнерах (тот же тредпул).
Кроме того должен быть какой то дескриптор развёртывания, где бы указывалось хотя бы количество процессоров на машине...
ну и какие то инные параметры приложения.
Spring по моему не предоставляет такого функционала из коробки ?
Это вероятно придётся реализовывать самому ? или и на этот случай что-то есть...
Понятно что это не самая не выполнимая задача, но всё же...

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

B>>Сервлеты тоже свободно без лишнизх усилий работают в многопоточной среде. Это никак не заслуга EJB.
ёё>Да сервлеты работают без лишних усилий потому что у них есть среда (сервлет контейнер) которая поддерживает для них многопоточность.

С помощью Spring можно к логике прикрутить любой многопоточный интерфейс, будь-то сервлеты, MQ, Socket Server или что ещё. Подобные фасады занимаются в частности тем что создают разные потоки под разные запросы извне.
Эти потоки работают через любые POJO. В чем тут сакраментальное превосходство EJB?

ёё>Ты не мог бы если не лень пояснить на примерах ?
Легко, дай мне пожалуйста EJB deployment descriptor, где можно конфигурять сколько CPU используется бином.

ёё>Spring по моему не предоставляет такого функционала из коробки ?
ёё>Это вероятно придётся реализовывать самому ? или и на этот случай что-то есть...
ёё>Понятно что это не самая не выполнимая задача, но всё же...
У меня радикально другие представления о EJB. Можно плз, ссылок по теме EJB работает на многопроцессорной машине лучше чем что-бы то либо?

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


B>С помощью Spring можно к логике прикрутить любой многопоточный интерфейс, будь-то сервлеты, MQ, Socket Server или что ещё.
B>Подобные фасады занимаются в частности тем что создают разные потоки под разные запросы извне.
Я же говорил, я не имею обширного опыта работы со spring'ом. По этому по многим вопросам это пока что для меня тёмный лес.
То есть иммется в виду что мы не только из сервлетов используем spring как контейнер для entity, но и сервлеты из спринга
в качестве "поточного фреймворка", что-то в этом духе ?

ёё>>Ты не мог бы если не лень пояснить на примерах ?
B>Легко, дай мне пожалуйста EJB deployment descriptor, где можно конфигурять сколько CPU используется бином.
Ну зачем же так...например при утановке ejb контайнера или сервера приложений наверняка эта информацию откуда-то берётся,
или системой инсталяции или прописывается инженером ?
(это всего лишь мои догадки).

ёё>>Spring по моему не предоставляет такого функционала из коробки ?
ёё>>Это вероятно придётся реализовывать самому ? или и на этот случай что-то есть...
ёё>>Понятно что это не самая не выполнимая задача, но всё же...
B>У меня радикально другие представления о EJB. Можно плз, ссылок по теме EJB работает на многопроцессорной машине лучше чем что-бы то либо?
Я не говорил что он работает лучше чем чтобы то ни було.
Просто мне трудно поверить, ejb такая дура...а тут какой то spring, довольно простая в своей сути штука.
Понятно что на него можно навесить наверное всё что угодно, вопрос в общем то был в том есть ли у спринга
заменители для функционала предоставляемого ejb'ями.
Похоже что есть...
И насколько сложно их настроить для работы с друг другом...
Похоже что не очень...

Спасиба, просвятил

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

ёё>Я же говорил, я не имею обширного опыта работы со spring'ом. По этому по многим вопросам это пока что для меня тёмный лес.
Не сочти за грубость, но мне кажется что и с EJB у тебя опыт не на много больше.

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

ёё>Просто мне трудно поверить, ejb такая дура...
Смотри книжки:
"Expert One-on-One J2EE Development without EJB"
"Better, Faster, Lighter Java"

ёё>а тут какой то spring, довольно простая в своей сути штука.
ёё>Понятно что на него можно навесить наверное всё что угодно, вопрос в общем то был в том есть ли у спринга
ёё>заменители для функционала предоставляемого ejb'ями.
Вопрос не только в Spring. Spring всего лишь средство интеграции. Но с помощью ряда opensource решений этим средством интегрируется все что заменяет EJB на раз.
Spring не является прямым аналогом EJB.

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

ёё>я где-то, когда-то читал, что приложение написаное в соответствии с ejb и исполняющееся в ejb контейнере
ёё>может свободно, без лишних усилий работать в многопоточной среде.
Ага, конечно. Кластеризацию stateless session beans оно тебе, может, и обеспечит без лишних усилий. Но под все остальное надо заранее проектировать и тестировать, прозрачная кластеризация — это вообще утопия.

В Spring'е все аналогично, но проще в использовании.

ёё>То по идее если развернуть на машине ejb приложение, оно будет исполнятся там оптимально
ёё>используя мультитрединг.
Аналогично со Spring'ом — используй оптимальные для задачи конфигурации фабрик.

ёё>А в случае спринг приложения наверно придётся делать каике-то хитрые движухи, если их
ёё>вообще можно зделать ? и какие ?
Для простого использования пулов потоков — все есть в самом Spring'е, ничего подключать не надо.

ёё>В случае кластеров ejb приложение будет пооддерживать распределённые транзакции между этими кластерами.
Ты неправильно понимаешь суть понятия "распределенная транзакция". Это не транзакция, работающая на кластере, а транзакция, в которой участвуют два или более источника. Например, база данных и JMS одновременно. Распределенных транзакций надо всеми силами избегать, в том числе и на кластерах.

ёё>Я не знаю сможет ли их поддерживать terracota, раз уж это нечто более, чем распределённый кеш ?
ёё>может какие то другие фреймворки ?
Terracotta — это простой метод организовать кластер. Есть и другие решения: GigaSpaces, Coherence, GridGain, ... — у каждого есть свои достоинства и недостатки. И естественно, все они интегрируются со Spring'ом. Это сейчас обязательное условие для нормальных продуктов

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

ёё>Я же говорил, я не имею обширного опыта работы со spring'ом. По этому по многим вопросам это пока что для меня тёмный лес.
ёё>То есть иммется в виду что мы не только из сервлетов используем spring как контейнер для entity, но и сервлеты из спринга
ёё>в качестве "поточного фреймворка", что-то в этом духе ?
Примерно так.

ёё>Ну зачем же так...например при утановке ejb контайнера или сервера приложений наверняка эта информацию откуда-то берётся,
ёё>или системой инсталяции или прописывается инженером ?
ёё>(это всего лишь мои догадки).
Это _может_ прописываться в отдельных appserver-specific конфигах.

ёё>Просто мне трудно поверить, ejb такая дура...а тут какой то spring, довольно простая в своей сути штука.
Тут как раз: "Краткость — сестра таланта".

ёё>Понятно что на него можно навесить наверное всё что угодно, вопрос в общем то был в том есть ли у спринга
ёё>заменители для функционала предоставляемого ejb'ями.
Да, _все_ возможности есть. Абсолютно все.

ёё>Похоже что есть...
ёё>И насколько сложно их настроить для работы с друг другом...
ёё>Похоже что не очень...
Я лично переместил сложное приложение с EJB3 (там использовалось JMS, JPA, JNDI и JMX) на Spring примерно за 3 дня. При этом, большая часть работы заключалась в cut&paste в конфиге. Работать оно после этого стало только лучше.

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

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

B>>Здравствуйте, denis.zhdanov, Вы писали:

DZ>>>здесь
B>>И JBoss treecache, эти двое на пару вроде бы самые перспективные.

ёё>А у меня вот сходу ещё такой возник вопрос:
ёё>Я на сколько понял и treecache & terracota это распределённые кеши ?

ёё>Я когда говорил о кластеризации имел в виду паралельное испольнение скажем, SLSB на кластерах, или просто
ёё>многопроцессорной машине ?

ёё>Известны какие то варианты как добится того же от spring'а ?

Сравнивать Терракоту с JB cache не стоит Терракота это пример виртуализации (объединения нескольких VM в одну виртуальную) во всеми проблемами конфигурации и выволенения вашего кода на разных VM ну а JB cache это в чистую data cache работающий на JGroups и имеющий tree like структуру позволяющую перемещать куски дерева вместо кучи данных.