Кто может что сказать по поводу производительности сабжевых бинов. бины BMP. предпологаемое количество одновременно крутящихся на сервере — 1500 одного класса и еще 30 000 второго. примерный обьем данных которые в бинах хранятся 500-600 мб .
Т.е есть путь юзать хранимые процедуры. либо юзать бины. количество пользователей в системе в районе 1500-3000. или ссылочки где про это можно прочитать. и как их производительность увеличить. есть ли Альтернативы.
Здравствуйте, NorthDragon, Вы писали:
ND>Кто может что сказать по поводу производительности сабжевых бинов. бины BMP. предпологаемое количество одновременно крутящихся на сервере — 1500 одного класса и еще 30 000 второго. примерный обьем данных которые в бинах хранятся 500-600 мб . ND>Т.е есть путь юзать хранимые процедуры. либо юзать бины. количество пользователей в системе в районе 1500-3000. или ссылочки где про это можно прочитать. и как их производительность увеличить. есть ли Альтернативы.
Альтернартивы есть всегда. Особенно в этом случае. Почитать в Expert One-on-One J2EE without EJB.
Плюс посмотреть на Hibernate.
Здравствуйте, Lucker, Вы писали:
L>Здравствуйте, NorthDragon, Вы писали:
ND>>Кто может что сказать по поводу производительности сабжевых бинов. бины BMP. предпологаемое количество одновременно крутящихся на сервере — 1500 одного класса и еще 30 000 второго. примерный обьем данных которые в бинах хранятся 500-600 мб . ND>>Т.е есть путь юзать хранимые процедуры. либо юзать бины. количество пользователей в системе в районе 1500-3000. или ссылочки где про это можно прочитать. и как их производительность увеличить. есть ли Альтернативы.
L>Альтернартивы есть всегда. Особенно в этом случае. Почитать в Expert One-on-One J2EE without EJB. L>Плюс посмотреть на Hibernate.
Спасибо. сейчас буду смотреть. а насчет производительности Entity EJB что скажете?
Здравствуйте, NorthDragon, Вы писали:
ND>Спасибо. сейчас буду смотреть. а насчет производительности Entity EJB что скажете?
Так вот с ними основная проблемма и есть. Это и ограниченность EJBQL, и трудности с импоементацией/деплойментом, оверхеад вызовов методов.
Помимо всего прочего использование Entity EJB начинает диктовать условия дизайну приложения, что совсем не хорошо сказывается на нем (на дизайне), так как приходится не технологию настраивать под нужды а нужды выводить согласно технологии. Вобщем, must die!
Здравствуйте, Lucker, Вы писали:
L>Здравствуйте, NorthDragon, Вы писали:
ND>>Спасибо. сейчас буду смотреть. а насчет производительности Entity EJB что скажете?
L>Так вот с ними основная проблемма и есть. Это и ограниченность EJBQL, и трудности с импоементацией/деплойментом, оверхеад вызовов методов. L>Помимо всего прочего использование Entity EJB начинает диктовать условия дизайну приложения, что совсем не хорошо сказывается на нем (на дизайне), так как приходится не технологию настраивать под нужды а нужды выводить согласно технологии. Вобщем, must die!
получается Entity совсем отстой.... или вся технология EJB по твоему отстой? почему тогда Sun ее поддерживает?
Здравствуйте, mselez, Вы писали:
M>Здравствуйте, NorthDragon, Вы писали:
ND>>получается Entity совсем отстой.... или вся технология EJB по твоему отстой? почему тогда Sun ее поддерживает?
M>где-то читал, что EJB полезна в 5-10 % случаев , в остальных лучше обойтись более простыми решениями типа Spring + Hibernate
Хотелось бы узнть, что относится к 5-10% а что ко всем остальным... по какому критерию разделяют. и по каким параметрами смотреть надо применять EJB или нет
Здравствуйте, NorthDragon, Вы писали:
ND>получается Entity совсем отстой.... или вся технология EJB по твоему отстой? почему тогда Sun ее поддерживает?
Боюсь навлечь на себя гнев праведный, но EJB дрова еще те
Здравствуйте, Am_Sasa, Вы писали:
A_S>Здравствуйте, NorthDragon, Вы писали:
ND>>получается Entity совсем отстой.... или вся технология EJB по твоему отстой? почему тогда Sun ее поддерживает?
A_S>Боюсь навлечь на себя гнев праведный, но EJB дрова еще те
Здравствуйте, NorthDragon, Вы писали:
ND>Хотелось бы узнть, что относится к 5-10% а что ко всем остальным... по какому критерию разделяют. и по каким параметрами смотреть надо применять EJB или нет
5-10% это приложения где необходима "true distributed" модель и где не требуются сложные выборки данных (и читать как AND). Во всех остальных случаях использование Entity EJB не оправдана. (Может я еще что пропустил?)
Здравствуйте, mselez, Вы писали:
ND>>получается Entity совсем отстой.... или вся технология EJB по твоему отстой? почему тогда Sun ее поддерживает?
M>где-то читал, что EJB полезна в 5-10 % случаев , в остальных лучше обойтись более простыми решениями типа Spring + Hibernate
здесь надо все-таки четко сказать — речь о EJB вообще или об Entity EJB в частности?
т.к. есть задачи, для которых Session EJB являются практически единственным стандартным переносимым подходом.
например, система, доступ к которой производится не только через Web GUI, а также через утилиты командной строки, свинг-клиенты. здесь Session EJB помогает для переносимого решения защиты этой системы от несанкционированного доступа на всех уровнях приложения, т.к. JAAS для всего этого хозяйства довольно неплохо специфицирован.
+ стоит помнить про message-driven beans
[skipped] L>Помимо всего прочего использование Entity EJB начинает диктовать условия дизайну приложения, что совсем не хорошо сказывается на нем (на дизайне), так как приходится не технологию настраивать под нужды а нужды выводить согласно технологии. Вобщем, must die!
А не подскажите где можно почитать в каких случаях применение Entity EJB является лишним, и неумеестным?
И неужели у него нет будущего? Обидно как то, что такая важная часть Java, не будет использоваться "по полной" и будет заменена чем-то вроде Hibernate(я не против, но больше нравиться использовать родные средства)
Может с реализацией 3-й спецификации все наладиться?
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, mselez, Вы писали:
ND>>>получается Entity совсем отстой.... или вся технология EJB по твоему отстой? почему тогда Sun ее поддерживает?
M>>где-то читал, что EJB полезна в 5-10 % случаев , в остальных лучше обойтись более простыми решениями типа Spring + Hibernate
C0s>здесь надо все-таки четко сказать — речь о EJB вообще или об Entity EJB в частности? C0s>т.к. есть задачи, для которых Session EJB являются практически единственным стандартным переносимым подходом. C0s>например, система, доступ к которой производится не только через Web GUI, а также через утилиты командной строки, свинг-клиенты. здесь Session EJB помогает для переносимого решения защиты этой системы от несанкционированного доступа на всех уровнях приложения, т.к. JAAS для всего этого хозяйства довольно неплохо специфицирован. C0s>+ стоит помнить про message-driven beans
Речь идет конкретно о Entity(BMP) bean'ах кол-во бинов одного типа — 30 000 и воторого типа 4000. Если надо какие то по-подробнее данные могу сказать подробнее.
Здравствуйте, andrew_g, Вы писали:
_>А не подскажите где можно почитать в каких случаях применение Entity EJB является лишним, и неумеестным?
http://www.theserverside.com
_>И неужели у него нет будущего? Обидно как то, что такая важная часть Java, не будет использоваться "по полной" и будет заменена чем-то вроде Hibernate(я не против, но больше нравиться использовать родные средства)
Да обидно. А ты сначала попробуй и то и другое. А потом расскажешь как тебе нравяться "родные" средства.
_>Может с реализацией 3-й спецификации все наладиться?
Читый там же. Много топиков на эту тему нужно только поискать.
Здравствуйте, Blazkowicz, Вы писали:
_>>Может с реализацией 3-й спецификации все наладиться?
B>Читый там же. Много топиков на эту тему нужно только поискать.
Может, если учитывать что реализацией 3-й спецификации будет основана на Hibernate3 , и что один из авторов спеки и есть автор Hibernate.
Если честно, на 3 еще даже не смотрел
Здравствуйте, NorthDragon, Вы писали:
ND>Речь идет конкретно о Entity(BMP) bean'ах кол-во бинов одного типа — 30 000 и воторого типа 4000. Если надо какие то по-подробнее данные могу сказать подробнее.
спасибо, не надо я "страшилки на ночь" лучше в художественной литературе/телевизоре поищу
если серьезно, берите hibernate, читайте hibernate_in_action, и, как результат, сделаете качественную работу с вашими объемами хранимых объектов
_>>>Может с реализацией 3-й спецификации все наладиться?
B>>Читый там же. Много топиков на эту тему нужно только поискать.
L>Может, если учитывать что реализацией 3-й спецификации будет основана на Hibernate3 , и что один из авторов спеки и есть автор Hibernate.
L>Если честно, на 3 еще даже не смотрел
ejb 3.0 для CMP бинов — крутая вещь. Hibernate сразу отметается
по теме: еджб не предназначен для bulk процессов (крутые sql действия)
(особенно при BMP бинах)
Здравствуйте, mselez, Вы писали:
M>где-то читал, что EJB полезна в 5-10 % случаев , в остальных лучше обойтись более простыми решениями типа Spring + Hibernate
я немного владею джавой потому что приходиться на делфи писать и поэтому есть пробелы в знаниях
обьясните пожалуйста что такое Spring + Hibernate и почему это лучше EJB в 90-95%
Здравствуйте, NVadim, Вы писали:
NV> ejb 3.0 для CMP бинов — крутая вещь. Hibernate сразу отметается
NV> по теме: еджб не предназначен для bulk процессов (крутые sql действия) NV> (особенно при BMP бинах)
а можно по-подробнее. что относится к крутым запросам. и какие причины малой производительности BMP бинов.
Спасибо за подсказку. ща буду смотреть 3 спецификацию
.
