Re[12]: Нормальная объектная декомпозиция vs EJB 3.
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 18.01.08 15:59
Оценка: 11 (2) :)
Здравствуйте, Cyberax, Вы писали:

C>Рефлексия ОЧЕНЬ быстрая, да еще и ускорить ее можно с помощью reflection optimizer'а. Можешь сам проверить — создание пары миллионов объектов с помощью рефлексии происходит очень быстро.


Хе-хе. Так мысль, что дело в рефлексии была появилась, когда заметили, что если смотреть стек-трейс тредов обработки данных из БД, то в 90% случаев всё стоит в AbstractEntityTuplizer и дальше java.lang.reflect. Эдакий ручной профайлер

Но, похоже, что вызов гетера через рефлексию всего в три раза медленнее прямого вызова метода. А Хиб сверху донаворачивает оверхеда еще на порядок.
Иллюстрация:
http://files.rsdn.org/38980/hib-proxy.png

Но эти тормоза обошли просто вытащив реальный объект из прокси. А вот медленную вычитку — никак
Я ненавижу Hibernate!
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re: Нормальная объектная декомпозиция vs EJB 3.
От: Blazkowicz Россия  
Дата: 12.12.07 18:06
Оценка: 6 (1) +1
Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Вопрос: я один такой? Подозреваю, меня сейчас в очередной раз отошлют к Spring, но времени на его изучение до сих пор нету.


Все верно. EJB3 лишь облегчает девелопмент, но подобные грабли Ejb2 как были так и будут. Тут некоторые уже рекомендовали использовать EJB только в качестве фасада. Логику же реализовывать отдельными легковесными классами. Но с ними-то не ясно как EJB DI использовать. А со Spring ты зря так. Какое там "время на изучение"? Там все просто, за пару часов можно IoC освоить. А остальное со временем прикрутится.
http://rsdn.org/File/13923/ukliam3.gif
Re[5]: Нормальная объектная декомпозиция vs EJB 3.
От: XJava  
Дата: 07.01.08 19:23
Оценка: -2
ДГ>Щас тебе Blazkowicz минус влепит. И я тоже влеплю, если не обоснуешь и не предложишь нормальных альтернатив. (Я как раз на неделе очень много гуглил по этому вопросу.)

Не нужно мне ничего лепить. Я человек мудренный опытом в этом деле.
Альтернативы: SWT, Qt Jambi
Re[3]: Нормальная объектная декомпозиция vs EJB 3.
От: Cyberax Марс  
Дата: 13.12.07 01:21
Оценка: 6 (1)
Здравствуйте, Дм.Григорьев, Вы писали:

B>>А со Spring ты зря так. Какое там "время на изучение"? Там все просто, за пару часов можно IoC освоить. А остальное со временем прикрутится.

ДГ>Я ждал этого замечания! Я развиваю уже работающий сайт, кто бы мне дал время его переписать. И есть у меня большое подозрение, что за пару часов всех ньюансов (в той же многопоточности) не освоишь.
Там не так все сложно — я перенес достаточно большой проект с EJB3 на Spring за два дня. Если не используются фичи типа распределенных транзакций и JMS — то большая часть работы будет заключаться в тупом cut&paste.
Sapienti sat!
Re[3]: Нормальная объектная декомпозиция vs EJB 3.
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 13.12.07 11:09
Оценка: 6 (1)
Дм.Григорьев,

B>>А со Spring ты зря так. Какое там "время на изучение"? Там все просто, за пару часов можно IoC освоить. А остальное со временем прикрутится.


ДГ>Я ждал этого замечания! Я развиваю уже работающий сайт, кто бы мне дал время его переписать. И есть у меня большое подозрение, что за пару часов всех ньюансов (в той же многопоточности) не освоишь. Кроме того, я тут вгрызаюсь в Swing, и боюсь, что параллельно ещё одно новшевство не потяну. (Всё чесались руки создать голосовалку: "Что такое — начинается на S, кончается на ing?" ) Вот и откладываю снова и снова.


Один мудрый человек говорил: вопрос нехватки времени — это вопрос расстановки приоритетов. (Это кстати вовсе не означает, что ты неправильно расставляешь приоритеты. Если времени на что-то не хватает — значит оно тебе не так уж и нужно).

Касаемо спринга вот этот (http://www.zaporozhye.org/rss/feed.php?channel=24&y=2006&m=08&d=05) пост мне очень нравится. Кстати, тебя никто не заставляет использовать именно spring. Можно ограничиться pico-, nano-контейнерами или Yan. Последний вообще можно прикрутить к чему угодно и куда угодно — совершенно неинтрузивен. Но конечно вокруг него нет такого хайпа, как вокруг спринга.
http://files.rsdn.org/10144/thinker.gif quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[10]: Нормальная объектная декомпозиция vs EJB 3.
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.01.08 14:39
Оценка: 6 (1)
Здравствуйте, Blazkowicz, Вы писали:

B>На одном форуме проскакивало: переписали проект с JDBC на Hibernate — стало в 10 раз медленнее. Вывод — Hibernate в 10 раз медленнее JDBC. Вот и тут похожая ситуация.


В 10 раз это преуменьшение. Я бы сказал в 1000 раз Вот я выложил результат запуска профайлера для чтения 1'000 объектов. JDBC calls 20мс из 5,5 тыс. мс. Подавляющее большинство времени занимает работа самого фреймворка. Самое интересное, что при росте числа объектов, обрабатываемых в одной сессии тормоза растут далеко не линейно! При том это не только моё мнение. Вот свежий пример сумнящегося в масштабируемости хибернейта. А вот бяка, которая вылазит при наличии L2-кеша и желания вставить/изменить много объектов. В результате выходит, что пока ты в работаешь с одним объектом, всё хорошо. А если тебе нужно массово обработать объекты, то с Хибом добро пожаловать в АдЪ Попытки исправить всё в лоб — больше загружать через lazy-load могут очень очень ухудшить положение. Любые попытки распаралелить обработку — это либо по сессии на тред и кардинальный рост занятой памяти плюс накладные расходы на вычитку объектов в разных тредах, либо попытка всё вычитать один раз и обрабатывать в разных тредах, тогда добро пожаловать в поисх ошибок связанных с ленивыми прокси. В этом случае LazyInitializationException — это большая удача, а всё может стать хитрее.

Судя по наличию такой проблемы у соседей по палате, э-э т.е. платформе
Автор: Sinix
Дата: 11.12.07
(цитата: "жалкие полтыщи /.../ строк должны загружаться по три-пять секунд") дело тут не только в Хибернейте. Как я помню, то при использовании ORM в Smalltalk (Glorp for VW) данные читались медленно (St всё таки ), но быстрее чем сейчас через Хибернейт (Это на PII-350 с 64Mb тогда против Core Duo 6600 с 2Гб сейчас)! Могу предположить, что дело в стоимости рефлексии (которую почему то считают ооочень быстрой в Java).

В итоге, я вполне допускаю, что готовить я Хибер просто не умею, но продукт, который призван что-то облегчать должен быть проще в готовке.
Я ненавижу Hibernate!
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[4]: Нормальная объектная декомпозиция vs EJB 3.
От: Дм.Григорьев  
Дата: 07.01.08 18:45
Оценка: :)
Здравствуйте, XJava, Вы писали:

XJ>Swing почти мертв (не категорично).


Щас тебе Blazkowicz минус влепит. И я тоже влеплю, если не обоснуешь и не предложишь нормальных альтернатив. (Я как раз на неделе очень много гуглил по этому вопросу.)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Нормальная объектная декомпозиция vs EJB 3.
От: Дм.Григорьев  
Дата: 12.12.07 16:45
Оценка:
Всем привет.

Не знаю, как сказать... В общем, меня несколько смущает, с какой скоростью нарастает количество stateless-бинов в EJB3-приложении, если делать его по уму (т.е. по ООП).

Разработку архитектуры я начинаю с прототипирования системы без привязки к какой-либо модели программирования вообще, и даже на concurrency не смотрю — только на логику. Потом оказывается, что для привязки к многопоточной EJB-модели и во избежание synchronization bottlenecks каждый мелкий класс бизнес-логики, реализующий независимый сервис, нужно оформлять отдельным SLSB (попутно обеспечивая поддержку множественности экземпляров сервиса). В итоге на JBoss-овский лог инициализации приложения смотреть страшно, возникает назойливое ощущение "неприятного запаха".

Вопрос: я один такой? Подозреваю, меня сейчас в очередной раз отошлют к Spring, но времени на его изучение до сих пор нету.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re[2]: Нормальная объектная декомпозиция vs EJB 3.
От: Курилка Россия http://kirya.narod.ru/
Дата: 12.12.07 18:12
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Все верно. EJB3 лишь облегчает девелопмент, но подобные грабли Ejb2 как были так и будут. Тут некоторые уже рекомендовали использовать EJB только в качестве фасада. Логику же реализовывать отдельными легковесными классами. Но с ними-то не ясно как EJB DI использовать. А со Spring ты зря так. Какое там "время на изучение"? Там все просто, за пару часов можно IoC освоить. А остальное со временем прикрутится.


Ммм, извиняюсь а DI в данном случае что есть такое?
Re[3]: Нормальная объектная декомпозиция vs EJB 3.
От: Blazkowicz Россия  
Дата: 12.12.07 18:29
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Ммм, извиняюсь а DI в данном случае что есть такое?


Dependency Injection контейнера. Его ведь не получится в своих классах использовать если EJB SFSB делать просто фасадом к этим классам.
http://rsdn.org/File/13923/ukliam3.gif
Re[2]: Нормальная объектная декомпозиция vs EJB 3.
От: Дм.Григорьев  
Дата: 12.12.07 19:09
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Все верно. EJB3 лишь облегчает девелопмент, но подобные грабли Ejb2 как были так и будут. Тут некоторые уже рекомендовали использовать EJB только в качестве фасада. Логику же реализовывать отдельными легковесными классами. Но с ними-то не ясно как EJB DI использовать.


Во. Из-за этого и вожусь с EJB. Спасибо, успокоил.

B>А со Spring ты зря так. Какое там "время на изучение"? Там все просто, за пару часов можно IoC освоить. А остальное со временем прикрутится.


Я ждал этого замечания! Я развиваю уже работающий сайт, кто бы мне дал время его переписать. И есть у меня большое подозрение, что за пару часов всех ньюансов (в той же многопоточности) не освоишь. Кроме того, я тут вгрызаюсь в Swing, и боюсь, что параллельно ещё одно новшевство не потяну. (Всё чесались руки создать голосовалку: "Что такое — начинается на S, кончается на ing?" ) Вот и откладываю снова и снова.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re[4]: Нормальная объектная декомпозиция vs EJB 3.
От: Аноним  
Дата: 13.12.07 09:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Там не так все сложно — я перенес достаточно большой проект с EJB3 на Spring за два дня. Если не используются фичи типа распределенных транзакций и JMS — то большая часть работы будет заключаться в тупом cut&paste.


Сор за оффтопю
Скажите а чем не угодил EJB3, что было приянто решение смигрировать на Spring?
Re[4]: Нормальная объектная декомпозиция vs EJB 3.
От: Blazkowicz Россия  
Дата: 13.12.07 11:21
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Касаемо спринга вот этот (http://www.zaporozhye.org/rss/feed.php?channel=24&amp;y=2006&amp;m=08&amp;d=05) пост мне очень нравится.

Все верно, кроме того что Spring MVC действительно не на сколько хорош как Spring в целом.

LCR>Кстати, тебя никто не заставляет использовать именно spring. Можно ограничиться pico-, nano-контейнерами или Yan. Последний вообще можно прикрутить к чему угодно и куда угодно — совершенно неинтрузивен. Но конечно вокруг него нет такого хайпа, как вокруг спринга.

В других контейнерах тоже нет проблем с декларативными транзакциями и их интеграции в J2EE?
http://rsdn.org/File/13923/ukliam3.gif
Re[5]: Нормальная объектная декомпозиция vs EJB 3.
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 13.12.07 12:27
Оценка:
Blazkowicz,

LCR>>Касаемо спринга вот этот (http://www.zaporozhye.org/rss/feed.php?channel=24&amp;y=2006&amp;m=08&amp;d=05) пост мне очень нравится.

B>Все верно, кроме того что Spring MVC действительно не на сколько хорош как Spring в целом.
Там невзначай так упоминается ROR. Я не смотрел оба фреймворка (только ROR), поэтому сравнивать не берусь. Если ты не согласен с автором — тебе и спорить (если конечно здесь возникнет человек, который смотрел оба и не согласен с тобой).

LCR>>Кстати, тебя никто не заставляет использовать именно spring. Можно ограничиться pico-, nano-контейнерами или Yan. Последний вообще можно прикрутить к чему угодно и куда угодно — совершенно неинтрузивен. Но конечно вокруг него нет такого хайпа, как вокруг спринга.

B>В других контейнерах тоже нет проблем с декларативными транзакциями и их интеграции в J2EE?
Это я так понимаю ты напираешь на фичастость Spring? Не надо, и так понятно, что в других контейнерах многое нужно будет делать ручками.
http://files.rsdn.org/10144/thinker.gif quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[5]: Нормальная объектная декомпозиция vs EJB 3.
От: Cyberax Марс  
Дата: 13.12.07 18:25
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Сор за оффтопю

А>Скажите а чем не угодил EJB3, что было приянто решение смигрировать на Spring?
Потому как нам не подходили стандартные инструменты в JBoss'е. После переноса на Spring мы написали свою систему сообщений, remoting-протокол и еще несколько подобных вещей.
Sapienti sat!
Re[5]: Нормальная объектная декомпозиция vs EJB 3.
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 14.12.07 07:51
Оценка:
Здравствуйте, Blazkowicz, Вы писали:
LCR>>Касаемо спринга вот этот (http://www.zaporozhye.org/rss/feed.php?channel=24&amp;y=2006&amp;m=08&amp;d=05) пост мне очень нравится.
B>Все верно

А как по мне, то этот спич — сплошная антиреклама.
Я ненавижу Hibernate!
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[6]: Нормальная объектная декомпозиция vs EJB 3.
От: yanys  
Дата: 14.12.07 08:35
Оценка:
ANS>А как по мне, то этот спич — сплошная антиреклама.
А вы могли бы как-то аргументировать это?
Re[7]: Нормальная объектная декомпозиция vs EJB 3.
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 14.12.07 09:17
Оценка:
Здравствуйте, yanys, Вы писали:

ANS>>А как по мне, то этот спич — сплошная антиреклама.

Y>А вы могли бы как-то аргументировать это?

Там же просто агитка. У меня агитки с нулём информации вызывают отторжение. Даже во фразе "svn лучше cvs" больше информации чем в этом страничном тексте.

Подробнее:
п.1 — набор слов.
п.2, п.3 — кубики — похоже на рекламу EJB. Что? Куда мне с EJB пойти? Ото ж.
п.4 — набор слов. Кстати, а что AOP действительно крутая штука?
п.5 — 7 — похоже я ошибся и кое какая инфа тут всё таки есть.
п.8 — рекомендации использовать SpringIDE. Н-да, а в п.1 было сказано, что Spring создан для упрощения жизни. Нам опять врали? И вообще "Выигрыш от чистого DI везде и всюду в более-менее большом приложении того стоит, не так ли?". Я, например, не уверен. Что теперь?
п.9 — ускорение в 1.4 по сравнению с 1.3 не служит доказательством "быстроты вообще".
п.10 — набор слов

Кстати, исходный текст, не смотря на рекламную направленость, таки можно прочитать и использовать. А это "не кратенький перевод" и даже не обещаный пересказ своими словами, а просто авторский поток мысли.
Я ненавижу Hibernate!
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: Нормальная объектная декомпозиция vs EJB 3.
От: XJava  
Дата: 07.01.08 18:36
Оценка:
ДГ>Я ждал этого замечания! Я развиваю уже работающий сайт, кто бы мне дал время его переписать. И есть у меня большое подозрение, что за пару часов всех ньюансов (в той же многопоточности) не освоишь. Кроме того, я тут вгрызаюсь в Swing, и боюсь, что параллельно ещё одно новшевство не потяну. (Всё чесались руки создать голосовалку: "Что такое — начинается на S, кончается на ing?" ) Вот и откладываю снова и снова.

Swing почти мертв (не категорично).
Re[6]: Нормальная объектная декомпозиция vs EJB 3.
От: Cyberax Марс  
Дата: 07.01.08 19:27
Оценка:
Здравствуйте, XJava, Вы писали:

XJ>Не нужно мне ничего лепить. Я человек мудренный опытом в этом деле.

XJ>Альтернативы: SWT
Немногим лучше Swing'а.

XJ>Qt Jambi

Не альтернатива вообще. Это скорее способ интеграции с QT для тех, кому это очень нужно. Так как стоит кучу денег и не имеет никаких преимуществ перед тем же SWT.
Sapienti sat!
Re[7]: Нормальная объектная декомпозиция vs EJB 3.
От: Дм.Григорьев  
Дата: 07.01.08 19:36
Оценка:
Здравствуйте, Cyberax, Вы писали:

XJ>>Альтернативы: SWT

C>Немногим лучше Swing'а.

А многие утверждают, что гораздо хуже. И в плане глючности, и в плане удобства написания своих компонент. Кроме того, сам факт использования нативных контролов гарантирует чудный секс при желании сделать шаг влево-вправо от готового. И наконец, я позавчера нарыл реализацию SWT API через Swing (правда, уже потерял).

XJ>>Qt Jambi

C>Не альтернатива вообще.

+1.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re[8]: Нормальная объектная декомпозиция vs EJB 3.
От: XJava  
Дата: 07.01.08 19:43
Оценка:
Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Здравствуйте, Cyberax, Вы писали:


Если Eclipse написан с использованием SWT, то он рулить реально.

Когда-то я участвовал в крутом Swing проекте стоимостью в млн. $.
Проект крутой и большой, но GUI тормозила ужасно.
Re[9]: Нормальная объектная декомпозиция vs EJB 3.
От: Cyberax Марс  
Дата: 07.01.08 19:48
Оценка:
Здравствуйте, XJava, Вы писали:

ДГ>>Здравствуйте, Cyberax, Вы писали:

XJ>Если Eclipse написан с использованием SWT, то он рулить реально.
Дело в том, что в самом Eclipse не так уж много контролов используется. Если их хватает — все нормально.

Если же чего-то не хватает — то все плохо. Такие вещи, как тот же JScrollPane в Swing'е в SWT не делаются нормально вообще.

XJ>Когда-то я участвовал в крутом Swing проекте стоимостью в млн. $.

XJ>Проект крутой и большой, но GUI тормозила ужасно.
Писали плохо
Sapienti sat!
Re[10]: Нормальная объектная декомпозиция vs EJB 3.
От: Дм.Григорьев  
Дата: 07.01.08 19:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

XJ>>Когда-то я участвовал в крутом Swing проекте стоимостью в млн. $.

XJ>>Проект крутой и большой, но GUI тормозила ужасно.
C>Писали плохо

Или под ОЧЕНЬ старый JRE. И вообще, XJava, поищи хотя бы по этому форуму.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re[4]: Нормальная объектная декомпозиция vs EJB 3.
От: Aib https://razborpoletov.com
Дата: 07.01.08 22:52
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Дм.Григорьев,


B>>>А со Spring ты зря так. Какое там "время на изучение"? Там все просто, за пару часов можно IoC освоить. А остальное со временем прикрутится.


ДГ>>Я ждал этого замечания! Я развиваю уже работающий сайт, кто бы мне дал время его переписать. И есть у меня большое подозрение, что за пару часов всех ньюансов (в той же многопоточности) не освоишь. Кроме того, я тут вгрызаюсь в Swing, и боюсь, что параллельно ещё одно новшевство не потяну. (Всё чесались руки создать голосовалку: "Что такое — начинается на S, кончается на ing?" ) Вот и откладываю снова и снова.


LCR>Один мудрый человек говорил: вопрос нехватки времени — это вопрос расстановки приоритетов. (Это кстати вовсе не означает, что ты неправильно расставляешь приоритеты. Если времени на что-то не хватает — значит оно тебе не так уж и нужно).


LCR>Касаемо спринга вот этот (http://www.zaporozhye.org/rss/feed.php?channel=24&amp;y=2006&amp;m=08&amp;d=05) пост мне очень нравится. Кстати, тебя никто не заставляет использовать именно spring. Можно ограничиться pico-, nano-контейнерами или Yan. Последний вообще можно прикрутить к чему угодно и куда угодно — совершенно неинтрузивен. Но конечно вокруг него нет такого хайпа, как вокруг спринга.


А что есть Yan? Не кинете ссылкой?
Re[5]: Нормальная объектная декомпозиция vs EJB 3.
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 08.01.08 08:07
Оценка:
Aib,

Aib>А что есть Yan? Не кинете ссылкой?


Yan container stands for Yet Another Non-intrusive container for object dependency injection.

Yan home
http://files.rsdn.org/10144/thinker.gif quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[9]: Нормальная объектная декомпозиция vs EJB 3.
От: Blazkowicz Россия  
Дата: 08.01.08 12:17
Оценка:
Здравствуйте, XJava, Вы писали:

XJ>Когда-то я участвовал в крутом Swing проекте стоимостью в млн. $.

XJ>Проект крутой и большой, но GUI тормозила ужасно.
На одном форуме проскакивало: переписали проект с JDBC на Hibernate — стало в 10 раз медленнее. Вывод — Hibernate в 10 раз медленнее JDBC. Вот и тут похожая ситуация.
http://rsdn.org/File/13923/ukliam3.gif
Re[11]: Нормальная объектная декомпозиция vs EJB 3.
От: Cyberax Марс  
Дата: 08.01.08 15:01
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>В 10 раз это преуменьшение. Я бы сказал в 1000 раз Вот я выложил результат запуска профайлера для чтения 1'000 объектов. JDBC calls 20мс из 5,5 тыс. мс. Подавляющее большинство времени занимает работа самого фреймворка. Самое интересное, что при росте числа объектов, обрабатываемых в одной сессии тормоза растут далеко не линейно!

Больше похоже на какие-то слишком жуткие глюки. Надеюсь, ты измерения проводил на "прогретом" коде?

ANS>При том это не только моё мнение. Вот свежий пример сумнящегося в масштабируемости хибернейта. А вот бяка, которая вылазит при наличии L2-кеша и желания вставить/изменить много объектов. В результате выходит, что пока ты в работаешь с одним объектом, всё хорошо. А если тебе нужно массово обработать объекты, то с Хибом добро пожаловать в АдЪ

Ага, натыкался. Почему-то их ассемблер объектов сильно тормозит в некоторых паталогических случаях с custom-типами. Причем СИЛЬНО тормозит.

ANS>Судя по наличию такой проблемы у соседей по палате, э-э т.е. платформе
Автор: Sinix
Дата: 11.12.07
(цитата: "жалкие полтыщи /.../ строк должны загружаться по три-пять секунд") дело тут не только в Хибернейте. Как я помню, то при использовании ORM в Smalltalk (Glorp for VW) данные читались медленно (St всё таки ), но быстрее чем сейчас через Хибернейт (Это на PII-350 с 64Mb тогда против Core Duo 6600 с 2Гб сейчас)! Могу предположить, что дело в стоимости рефлексии (которую почему то считают ооочень быстрой в Java).

Рефлексия ОЧЕНЬ быстрая, да еще и ускорить ее можно с помощью reflection optimizer'а. Можешь сам проверить — создание пары миллионов объектов с помощью рефлексии происходит очень быстро.

ANS>В итоге, я вполне допускаю, что готовить я Хибер просто не умею, но продукт, который призван что-то облегчать должен быть проще в готовке.

Так ведь облегчает Иначе никто бы им не пользовался.

Я был на JUG'е где Mike Keith пиарил http://www.eclipse.org/eclipselink/ Сейчас я на него смотрю — вроде бы примерно на уровне Hibernate фичи и работает быстрее. Можно попробовать его еще.
Sapienti sat!
Re[12]: Нормальная объектная декомпозиция vs EJB 3.
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.01.08 15:21
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Больше похоже на какие-то слишком жуткие глюки. Надеюсь, ты измерения проводил на "прогретом" коде?


Верю, но что делать — так и не понятно Это, кстати, синтетический тест. А в реале всё еще хуже

C>Ага, натыкался. Почему-то их ассемблер объектов сильно тормозит в некоторых паталогических случаях с custom-типами. Причем СИЛЬНО тормозит.


Там не только ассемблер. Если вычитать в сессии много объектов, а потом вне транзакции делать find(), то всё — туши свет.

C> ускорить ее можно с помощью reflection optimizer'а


Этого? ;)

C>Так ведь облегчает Иначе никто бы им не пользовался.


Возникло просто сомнение, что им кто-то пользуется Никаких советов, кроме использования pre-fetching-а и L2-кеша для ускорения пообъектного доступа я особо не видел. И то этот совет слишком банальный. А при любых указаниях на тормоза один ответ — у нас всё хорошо, а вот вам не нужно столько объектов за раз. Спасибо, хоть ты такого не сказал

C>Я был на JUG'е где Mike Keith пиарил http://www.eclipse.org/eclipselink/ Сейчас я на него смотрю — вроде бы примерно на уровне Hibernate фичи и работает быстрее. Можно попробовать его еще.


Это же toplink. Говорят он такой глючный, что мне даже смотреть на него боязно
Я ненавижу Hibernate!
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[12]: Нормальная объектная декомпозиция vs EJB 3.
От: Дм.Григорьев  
Дата: 08.01.08 17:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

ANS>>В итоге, я вполне допускаю, что готовить я Хибер просто не умею, но продукт, который призван что-то облегчать должен быть проще в готовке.


+1.

C>Так ведь облегчает Иначе никто бы им не пользовался.


ИМХО, Hibernate отнюдь не производит впечатление интуитивно-понятной вещи, даже на уровне юзера. Вот допустим есть у меня замапенный List<MenuItem> Menu.items, <list><list-index></list> в Menu.hbm.xml, и <many-to-one> в MenuItem.hbm.xml. Если в <many-to-one> забыть not-null="true", маппинг работать не будет. Молча. Я дважды наступал на эти грабли, и парился по часу, всё проклиная. Кто скажет, что такой простой use case нельзя было сделать по-человечески, пусть первый бросит в меня камень.

C>Я был на JUG'е где Mike Keith пиарил http://www.eclipse.org/eclipselink/ Сейчас я на него смотрю — вроде бы примерно на уровне Hibernate фичи и работает быстрее. Можно попробовать его еще.


Хм...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re[13]: Нормальная объектная декомпозиция vs EJB 3.
От: Cyberax Марс  
Дата: 08.01.08 20:12
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

C>>Больше похоже на какие-то слишком жуткие глюки. Надеюсь, ты измерения проводил на "прогретом" коде?

ANS>Верю, но что делать — так и не понятно Это, кстати, синтетический тест. А в реале всё еще хуже
Попробуй с дебаггером залезть внутри Hibernate

Кстати, еще же JDO есть — попробуй на досуге benchmark'и поделать на нем. По идее, он тебе должен больше подходить.

C>>Ага, натыкался. Почему-то их ассемблер объектов сильно тормозит в некоторых паталогических случаях с custom-типами. Причем СИЛЬНО тормозит.

ANS>Там не только ассемблер. Если вычитать в сессии много объектов, а потом вне транзакции делать find(), то всё — туши свет.
Странно, у меня это работает быстро.

C>> ускорить ее можно с помощью reflection optimizer'а

ANS>Этого? ;)
Ага

C>>Так ведь облегчает Иначе никто бы им не пользовался.

ANS>Возникло просто сомнение, что им кто-то пользуется Никаких советов, кроме использования pre-fetching-а и L2-кеша для ускорения пообъектного доступа я особо не видел. И то этот совет слишком банальный. А при любых указаниях на тормоза один ответ — у нас всё хорошо, а вот вам не нужно столько объектов за раз. Спасибо, хоть ты такого не сказал
Я пользуюсь L2-кэшем. Специально даже его пинал ногами, чтоб работал — время, действительно, экономит. Но у меня проблема в том, что есть куча сложносвязаных объектов, для загрузки которых потребовалось бы много мелких запросов к БД.

C>>Я был на JUG'е где Mike Keith пиарил http://www.eclipse.org/eclipselink/ Сейчас я на него смотрю — вроде бы примерно на уровне Hibernate фичи и работает быстрее. Можно попробовать его еще.

ANS>Это же toplink. Говорят он такой глючный, что мне даже смотреть на него боязно
Да, это бывший Toplink. Не знаю как насчет глючности, но мне в нем понравилось то, что они умеют "из коробки" представлять набор изменений в транзакции в виде красивых changeset'ов. В Hibernate для этого я делал грязные хаки.

Пока я на него переходить не хочу, подожду еще годик, чтобы он подрос (или умер окончательно). Пока мне слишком нравится поддержка Hibernate в IDEA
Sapienti sat!
Re[13]: Нормальная объектная декомпозиция vs EJB 3.
От: Cyberax Марс  
Дата: 08.01.08 20:14
Оценка:
Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>ИМХО, Hibernate отнюдь не производит впечатление интуитивно-понятной вещи, даже на уровне юзера. Вот допустим есть у меня замапенный List<MenuItem> Menu.items, <list><list-index></list> в Menu.hbm.xml, и <many-to-one> в MenuItem.hbm.xml. Если в <many-to-one> забыть not-null="true", маппинг работать не будет. Молча. Я дважды наступал на эти грабли, и парился по часу, всё проклиная. Кто скажет, что такой простой use case нельзя было сделать по-человечески, пусть первый бросит в меня камень.

Меня больше бесили странные сообщения об ошибках. Точнее, их отсутсвтие — Hibernate просто падает в середине какого-либо метода.
Sapienti sat!
Re[14]: Нормальная объектная декомпозиция vs EJB 3.
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.01.08 09:41
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Кстати, еще же JDO есть — попробуй на досуге benchmark'и поделать на нем.


Попробуй лучше ты попрофайлить вычитывание списка в 1'000-10'000 элементов в Hibernate. Вопрос, кстати, не теоретический, а именно практический.

C>По идее, он тебе должен больше подходить.


Может и так. Вообще я понимаю. что наезд не совсем в кассу. Пишут же люди на ROR и не жужжат. Но там они знают на что идут и от Жабы я ожидал большей масштабируемости чем от Ruby

C>Странно, у меня это работает быстро.


Там 2 прикола. Если вызывать find() вне транзакции, то в обязательном порядке для всех объектов в сессии вызывается некий unlock (см. SessionImpl.get() -> SessionImpl.afterOperation(); возможно потом StatefulPersistenceContext.afterTransactionCompletion(), не помню точно). Вот, судя по профайлеру сам процесс итерации по всем entries и тормозит! Если этих find-ов больше одного, то заметно тормозит И хоть стой хоть падай, а время этой итерации не знаю как сократить. Точнее знаю — нужно все find вызывать в транзакции. Но если в сессии много объектов, то завершение транзакции (поисх изменённых объектов) занимает кучу времени!

Второй прикол с find() вылазит если все find() таки делать в одной транзакции. Оказывается доставание уже вычитанного (закешированного в сессии) объекта тоже относительно медленная операция (хотя я не помню это было принципиально или нет).

Иллюстрация (1'000 find):
http://files.rsdn.org/38980/hib-tormoz.png

Выход — не использовать find(), а ходить по связям в объектах. Правда каждая связь добавляет сущность, которая ляжет в сессию...

C>Я пользуюсь L2-кэшем. Специально даже его пинал ногами, чтоб работал — время, действительно, экономит.


Пользуемся EhCache, (afaik ) Тоже не быстрая штука

C>Но у меня проблема в том, что есть куча сложносвязаных объектов, для загрузки которых потребовалось бы много мелких запросов к БД.


Угу. А если делать pre-fetch, то мало того, что вычитываются возможно не нужные объекты, но и сессия засерается с вытекающими отсюда тормозами.

C>Пока я на него переходить не хочу, подожду еще годик, чтобы он подрос (или умер окончательно). Пока мне слишком нравится поддержка Hibernate в IDEA


В любом случае у нас много гибернетизмов Нет уверенности, что легко запустить будет под toplink/eclipselink.
Я ненавижу Hibernate!
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[15]: Нормальная объектная декомпозиция vs EJB 3.
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.01.08 12:26
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Иллюстрация (1'000 find):

Туда же:
http://files.rsdn.org/38980/hib-tormoz-find-hotspot.png
п.2,3,4 входят в состав п.1
Я ненавижу Hibernate!
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[16]: Нормальная объектная декомпозиция vs EJB 3.
От: Blazkowicz Россия  
Дата: 09.01.08 12:44
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, Andrei N.Sobchuck, Вы писали:


ANS>>Иллюстрация (1'000 find):

ANS>Туда же:
ANS>http://files.rsdn.org/38980/hib-tormoz-find-hotspot.png
ANS>п.2,3,4 входят в состав п.1

Оно?
http://rsdn.org/File/13923/ukliam3.gif
Re[17]: Нормальная объектная декомпозиция vs EJB 3.
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.01.08 13:15
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Оно?


О, спасибо, это интересно. Я искал только баги по 3.2.3+. Ровно 2 года с момента репорта

Решение в общем почти то же, что у мужика в баге. Сделали по максимум доступ через ссылки в уже загруженных объектах, плюс доп-кеширование на уровне сессии. Но когда вводили гибернейт, то было желание избавиться от наших кешей, а не перенаворачивать их сверху хибернейта С find() ожидалось, что не будет проблем c владением объектами (когда объект с ленивыми проксями передаётся в другой тред. Ан нет — и кеши свои пришлось приделать и проблемы с владением решать.

Кстати, похоже в баге там еще не все условия указаны. Нужно что-бы jdbc-конекшен релизился из сессии после транзакции/запроса (releaseMode). Если конекшен не релизится в течение жизни хиб-сессии, то вроде проблемный метод не вызывается.
Я ненавижу Hibernate!
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[15]: Нормальная объектная декомпозиция vs EJB 3.
От: Cyberax Марс  
Дата: 09.01.08 15:47
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

C>>Кстати, еще же JDO есть — попробуй на досуге benchmark'и поделать на нем.

ANS>Попробуй лучше ты попрофайлить вычитывание списка в 1'000-10'000 элементов в Hibernate. Вопрос, кстати, не теоретический, а именно практический.
Обязательно попробую на досуге.

C>>Странно, у меня это работает быстро.

ANS> Но если в сессии много объектов, то завершение транзакции (поисх изменённых объектов) занимает кучу времени!
Это можно переопределить при желании — нужно поставить Interceptor в котором добавить свою обработку onFlushDirty.

ANS>Второй прикол с find() вылазит если все find() таки делать в одной транзакции. Оказывается доставание уже вычитанного (закешированного в сессии) объекта тоже относительно медленная операция (хотя я не помню это было принципиально или нет).

Можно попробовать исправить

C>>Я пользуюсь L2-кэшем. Специально даже его пинал ногами, чтоб работал — время, действительно, экономит.

ANS>Пользуемся EhCache, (afaik ) Тоже не быстрая штука
У меня хуже — распределенный JBoss Cache

C>>Но у меня проблема в том, что есть куча сложносвязаных объектов, для загрузки которых потребовалось бы много мелких запросов к БД.

ANS>Угу. А если делать pre-fetch, то мало того, что вычитываются возможно не нужные объекты, но и сессия засерается с вытекающими отсюда тормозами.
У меня оно еще просто и очень сложно делается.

C>>Пока я на него переходить не хочу, подожду еще годик, чтобы он подрос (или умер окончательно). Пока мне слишком нравится поддержка Hibernate в IDEA

ANS>В любом случае у нас много гибернетизмов Нет уверенности, что легко запустить будет под toplink/eclipselink.
Просто они, вроде бы, очень похожи. В общем, интересно посмотреть что получится из Eclipselink в итоге. Hibernate'у уже давно пора хорошего конкуррента получить.
Sapienti sat!
Re[16]: Нормальная объектная декомпозиция vs EJB 3.
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.01.08 15:57
Оценка:
Здравствуйте, Cyberax, Вы писали:

ANS>> Но если в сессии много объектов, то завершение транзакции (поисх изменённых объектов) занимает кучу времени!

C>Это можно переопределить при желании — нужно поставить Interceptor в котором добавить свою обработку onFlushDirty.

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

Кстати, странно, что кеши (L1 & L2) не кешируют отсутсвтие объектов.
Я ненавижу Hibernate!
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.