Всем привет!

Такая ситуация: нужно написать BMP Entity Bean, который должен отображать некоторую статистику, но не вносит никаких изменений в базу. Отбор статистики производится в MS SQL базе некоторой функцией, которая возвращает числа статистики. Функция довольно тяжелая и отрабатывает на БД-сервере порядка 4-5 секунд.

Чтобы было понятней, покажу обьявление функции из БД:

Предлагаю на суд всем вам, как я собираюсь это сделать. Скажите пожалуйста, правильно ли я собираюсь сделать, или можно лучше?

Так вот, если написать энтити бин ClientStat, то его первичный ключ будет содержать два поля: clientID, statType. Сам же BMP будет содержать в своих свойствах класса цифры статистики.

По правилам создания BMP, необходимо определить метод FindByPrimaryKey, который должен будет определить, есть ли статистика для указанного ключа (в данном случае, это поля clientID и statType). Затем необходимо определить метод ejbLoad для загрузки статистики в свойства класса.

Таким образом, по технологии, в методе FindByPrimaryKey нужно вызывать функцию fGetClientStat, чтобы определить, есть ли статистика для этого набора параметров, и эту же функцию нужно повторно вызывать и в методе ejbLoad уже для загрузки. Что меня в этом случае смущает... Получается, тяжелая сиквельная функция будет вызываться два раза!! Что займет 10 секунд времени для пользователя, ожидающего статистики, и сьест на это время серверные ресурсы!!

Как решить проблему, чтобы не вызывать сиквельную функцию два раза??


Я придумал такой вариант решения. Метод FindByPrimaryKey не лезет в базу вобще, и просто возвращает переданный в параметре первичный ключ. Метод же ejbLoad пытается загрузить статистику при помощи сиквельной функции, и, если не получается, возвращает javax.ejb.NoSuchEntityException. А этот эксепшн я уже буду перехватывать в сесионном бине, и выводить свое сообщение, что статистика не найдена.

Таким образом, я буду вызывать сиквельную функцию один раз, а не два

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

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

Да, действительно, лучше сделать так... Правда, при этом, если я буду вызывать jdbc-запросы непосредственно из Session Bean, будет нарушена идея пятиуровневой архитектуры. В случае использования сущностного бина, я имел бы разные уровни: бизнес-логика (сессионный бин), сопоставление данных (энтити бин), и сами данные (МС Сиквел Сервер). Если же jdbc-запросы будут выполняться непосредственно из сесионного бина, здесь будет только два уровня: бизнес-логика и данные. Поэтому, наверное, лучше заменить сущностный бин на соответствующий маппер, для сохранения отделения бизнес-логики от формата данных. Как думаешь?

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


Timmкак вариант, можно слегка обманывать и кэшировать результаты выполнения хп (механизм кэширования - отдельная тема), в ejbFindByPrimaryKey() выбирать данные из кэша (если есть) и если данные "считаются актуальными". в противном случае - вызывать хп, синхронизировать кэш и т.д.
собственно, в ejbLoad можно инициализировать инстанс из данных кэша...
Мне поручили разобраться в технологии J2EE, и дали задание сделать реальную задачу (описанную выше) в качестве теста возможностей J2EE. Хотелось бы, конечно, научиться пользоваться Entity Bean тоже, и было бы неплохо их притулить в эту задачу... Но, действительно, энтити бины здесь лишни... Жаль, не буду с ними учиться пока-что работать... :(

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

Я тут вот раздумываю насчет шаблона FatKey: http://www.theserverside.com/patterns/thread.tss?thread_id=4540 .
Если кратко: cуть в том, что в Key запихываются также все необходимые данные в методах поиска. Затем в ejbLoad эти данные загоняются в поля бина непосредственно из ключа (без доступа к базе). При этом в ключе поля данных объявлены как transient.
Только я стремаюсь немножко использовать этот шаблон... Что-то сдается мне, ненадежен он...


Timm2) VetalПравда, при этом, если я буду вызывать jdbc-запросы непосредственно из Session Bean, будет нарушена идея пятиуровневой архитектуры.
ну и что? за идею боретесь? :-)

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


Timmкстати что возвращает функция?

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

jdev333 Правда, при этом, если я буду вызывать jdbc-запросы непосредственно из Session Bean, будет нарушена идея пятиуровневой архитектуры

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