@mr_dronski

Есть бин, примерно 200-300 записей в базе, которые он представляет. Эти записи обновляются каждый день в 15:00 GMT. Скорее всего, нужно будет полностью сносить все записи и создавать новые в этот момент. Иначе очень много возни с определением устаревших записей, определением новых (устаревшие считаются несуществующими, поэтому их нельзя выдавать клиенту).

В остальное время клиент имеет только read-only access. То есть, имеем read-mostly EJB.

Пока это все на стадии разработки архитектуры, поэтому есть время все поменять. Меня волнуют пару вопросов:

1. Ваш опыт оптимизации read-mostly beans, неважно на каком сервере.
2. Стоит ли затевать именно эту часть с EJB? Чего пооблегченнее тоже подыскиваю.

0

@vold

Откуда только такие паттерны достаются... В EJB Design patterns про них ни слова, на Сане - молчек, есть ссылки на серверСайде, однако так и не смог найти описания...
А в чем проблема-то? Можно более ясными словами (или может ссылку на этот хитрый паттерн)

0

@mr_dronski

практика и не такое подкинет

это скорее не паттерн, а принцип (хохма . упоминания про такой тип работы встречал где-то в веблогике и в jboss'e проскальзывало.

частично это решалось установкой бина в read-only, с cache timeout.

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

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

лезет немало мыслей в голову. напрашивается использование Session Bean + DAO. хотя больше вопросов из-за такой связки возникает, чем ответов. поэтому и ковыряю

а дальше еще поинтереснее задачку смогу подкинуть, со временем

0

@Danissimo

А что если для чтения и обновления использовать разные техники, что ли:
.) для чтения пользоваться JDBC напрямую, результат не оборачивать в DTO, а передавать as is, только обернуть и закешировать для serialization, если вызовы удаленные, или, если неудаленные, все равно обернуть и закешировать, чтобы освободить ресурсы БД (а также открыть только операции чтения);
.) для обновления использовать entiy beans.

Обе эти техники скрыть от клиента за фасадом, который будет блокировать чтение до тех пор, пока не выполнится обновление (чтобы не выполнять dirty read). Здесь встает задача, как организовать блокирование.

А если и для updat'а отказаться от entity beans, то и блокировать ничего не нужно будет. А логику чтения или обновления JDBC можно скрыть в отдельном классе.

0

@vold

2Danis
>>А что если для чтения и обновления использовать разные техники, что ли
-Дык это типа стандарта де-факто(пробовали когда-нибудь вытащить на клиента 300 строк в виде коллекции объектов? сколько времени это занимает?

Насколько я понимаю вопрос в закрытии для клиента возможности осуществлять 'грязное' чтение в те самые 15-20 секунд, а это, боюсь уже уровень БД, или нужно использовать пользовательские транзакции, если речь идет о ЕнтБинах.

Я подозреваю, что обновление данных происходит на уровне логики БД, тогда изоляция зависит от этой самой логики, так, например, на оракле, по дефолту запрещено грязное чтение, т.е. хоть 10 часов транзакция идет, но юзер будет иметь доступ только к данным, которые имелись на ее начало, а по окончании уже к свежим данным....

Или я чего-то не понимаю, но по-моему паттерны здест не причем, дело просто в изоляции, и логике БД...

А сессионный бин + DTO - по моему тоже стандарт де-факто (вопрос - а что еще вообще бывает при передаче данных на клиента). Теоретически можно реализовывать интерфейс ResultSet, или еще как исхитряться, но мне в реальной жизни не пришлость видеть как удачных реализаций использования других техник, так и необходимости их использования...

0

@Danissimo

2 Vold

Недавно видел, кусочек какой-то передачи, где Горбачев что-то говорил. У него особенность есть одна: вот начинает мысль, говорит, говорит что-то, ведет ее, ведет, потом -- раз! -- когда нужно подъитожить, переключается, не прерывая плавного потока слов, мягко льющегося с уже почти забытым тембром, и первоначальная мысль растворяется как утренний туман.

Что ты хотел сказать?.. (можно не отвечать :-)) Наверное, что-то очень умное :-) Разве я утверждал, что что-то новое скажу, а? ;-)

2 all

Итак.

> 1. Ваш опыт оптимизации read-mostly beans, неважно на каком сервере.
> 2. Стоит ли затевать именно эту часть с EJB? Чего пооблегченнее тоже подыскиваю.

Я бы отказался от entity. Доступ к БД на чтение и запись через один и тот же фасад. DTO заменил бы на что-то типа RowSet'а, но очень облегченного (т.е. с минимумом необходимых операций). Запрсы к БД обернул бы в отдельный класс. Все.

По performanc'у нет ничего быстрее. При портировании возможно (!) придется переписать SQL, изолированный в отдельные классы. Причем этого можно попытаться избежать, если стремиться использовать только стандарт SQL. Облегчаем жизнь себе и клиенту при кодировании и отладке из-за strong-typing в обертке ResultSet'а.

Минусы: один раз нужно правильно (!) написать инициирование запроса к БД и завершение выполнения запроса. Еще минус -- запрос пишем явно. Это даже к минусам относить-то стыдно. Правда из-за этого минус посерьезнее -- портируемость. Облегчаем жизнь себе, используя стандарт.

2 Vold

Теперь о блокировке при чтении во время записи. При изоляции читателя readcommitted какая разница, какая там блокировка на запись. Эта блокировка гарантирует, что вторая запись встанет в очередь и все.

0

@vold

2Danis
>>Что ты хотел сказать?.. <<
Честно говоря ничего особенного ;-)
просто хотелось яснее осознать траблу :-
по моему, при данной постановке задачи никакой траблы нет..
да и ты говоришь о возможных общих стратегиях дизайна.

просто я хотел уточнить, насколько я понимаю, в данной ситуации на сервере БД в 15:00 запускается sp, которая одной транзакцией грохает записи и заносит новые, так мне кажется что предоставление 'не грязной' инфы есть забота сервера БД (если я правильно понимаю задачу), а разработка дизайна системы, на уровне ап. сервера, это уже другой уровень...

>>Теперь о блокировке при чтении во время записи<< - или у меня глюки или я ничего не говорил про блокировки :-О

0

@vold

2Danis

А... понятно, ты валишь в одну кучу блокировки, изоляции, 'читателей' и 'писателей'.
Какой бы уровень изоляции не стоял у читателя, если на сервере идет сериализуемая транзакция, то бедный 'читатель' будет сидеть и угрюмо ждать ее завершения...
если на сервере идет транзакция самого позволяющая незакрепленное чтение, то бедный 'читатель' благополучно прочтет данные, которые по завершении транзакции будут откачены

0

@Danissimo

О каком сервере речь?
Я, например, говорил о СУБД :-)
Старик, ты опять что-то непонятно что говоришь :-)

0

@mr_dronski

наверное, я сотворю что-то наподобие такого:

при старте всего хозяйства вычитываем и кэшируем всю таблицу в ApplicationContext. - в одном месте так уже делается. весь SQL выносится в env-entry, поэтому с портируемостью особых проблем нет.

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

на апп сервере мы можем в час Ч запустить прогу - даже не EJB, выставим ей transaction serializable на время ковыряния базы. для портируемости будем юзать DAO.

запутанно, но неплохая отправная точка.

а про транзакции хороший вопрос, продолжаем обсуждение.

0

@Danissimo

а в чем, собсно?

0