Привет всем . Такую проблему никак не могу решить...
Вобщем, есть n-пользователей какой-либо системы. Все пользователи работают с базой данных, причём статистика указывает на то, что активно используется только часть базы данных. Логично предположить, что для оптимизации работы сервера можно было бы кэшировать такие данные в оперативную память, как не крути, а работа с оперативной памятью по скорости опережает все остальные источники данных... Теперь вопрос: как осуществить такое кэширование ? (планировал сделать это с помощью EJB, но , пока не нашёл решение данной проблемы...) Прошу помощи
Здравствуйте, ALER_PROG, Вы писали:
ALE>Привет всем . Такую проблему никак не могу решить... ALE>Вобщем, есть n-пользователей какой-либо системы. Все пользователи работают с базой данных, причём статистика указывает на то, что активно используется только часть базы данных. Логично предположить, что для оптимизации работы сервера можно было бы кэшировать такие данные в оперативную память, как не крути, а работа с оперативной памятью по скорости опережает все остальные источники данных... Теперь вопрос: как осуществить такое кэширование ? (планировал сделать это с помощью EJB, но , пока не нашёл решение данной проблемы...) Прошу помощи
Надо реализовать кэширование самому или взять готовую библиотеку (ehcache, oscache, TreeCache). В любом случае надо написать прослойку (в виде DAO-объектов), в которых реализуется логика кеширования. Или просто переписать весь код, где происходит получение данных, добавив во все места поддержку кэша
Здравствуйте, Michael_Y, Вы писали:
M_Y>Здравствуйте, ALER_PROG, Вы писали:
ALE>>Привет всем . Такую проблему никак не могу решить... ALE>>Вобщем, есть n-пользователей какой-либо системы. Все пользователи работают с базой данных, причём статистика указывает на то, что активно используется только часть базы данных. Логично предположить, что для оптимизации работы сервера можно было бы кэшировать такие данные в оперативную память, как не крути, а работа с оперативной памятью по скорости опережает все остальные источники данных... Теперь вопрос: как осуществить такое кэширование ? (планировал сделать это с помощью EJB, но , пока не нашёл решение данной проблемы...) Прошу помощи
M_Y> Надо реализовать кэширование самому или взять готовую библиотеку (ehcache, oscache, TreeCache). В любом случае надо написать прослойку (в виде DAO-объектов), в которых реализуется логика кеширования. Или просто переписать весь код, где происходит получение данных, добавив во все места поддержку кэша
Ну , как бы, понятно, что это будет реализовано мной . Просто для меня , узким местом стало то, В ЧЁМ ЭТО ХРАНИТЬ ! То есть нужен некий объект, который ПОСТОЯННО находится в памяти (именно в оперативной) и к которому возможен доступ всеми пользователями . То есть что-то вроде глобального хранилища данных , но в оперативной памяти, а не в БД...
Здравствуйте, LDimas, Вы писали:
LD>Если использовать Hibernate то решение — Second Level Cache. LD>О том как его использовать, можно почитать в Hibernate Reference раздел 19.2
Вы этим пользовались ?...точнее, к скэшированным данным (ОБЩИМ ДАННЫМ, ГЛОБАЛЬНЫМ) смогут получить досутп все пользователи системы ?
Здравствуйте, LDimas, Вы писали:
LD>Здравствуйте, ALER_PROG, Вы писали:
ALE>>Ну , как бы, понятно, что это будет реализовано мной .
LD>А не лучше ли взять готовое решение, да посмотреть как работает? Вот про кеш hibernate я писал уже.
А есть какие-то альтернативные методы решения данной проблемы ? Скажем , если не использовать какие-либо источники данных... Скажем, просто, массив данных, который доступен всем пользователям....и т.п. То есть какие-то глобальные данные , которые не относятся к какому-либо источнику...Просто накапливаются в процессе работы и используются совместно...
Здравствуйте, ALER_PROG, Вы писали:
ALE>Здравствуйте, LDimas, Вы писали:
LD>>Если использовать Hibernate то решение — Second Level Cache. LD>>О том как его использовать, можно почитать в Hibernate Reference раздел 19.2 ALE>Вы этим пользовались ?...точнее, к скэшированным данным (ОБЩИМ ДАННЫМ, ГЛОБАЛЬНЫМ) смогут получить досутп все пользователи системы ?
Для того, чтобы ответить на ваш вопрос, необходимо знать архитектуру системы.
1. Как устроено взаимодействие пользователей с системой (orm jdbc ejb)?
2. Где конкретно располагается "оперативная память" и как предполагается доступ
к это "памяти" n пользователей.
Проблема эффективной реализации актуальности данных в распределенных системах — та еще
задачка... Вы уверены, что без теоретических знаний по этой теме готовы сделать свою
реализацию?
Обычно это делается:
1. Тонкий клиент: Все кеширование происходит на сервере приложений,
а обновление происходит по событиям уровня бизнес-логики.
2. Толстый клиент: Доступ и логика работы с бд осуществляется на клиенте, и
кеширование занимается клиент, тогда синхронизация осуществляется кешем
2-го уровня из перечисленных выше (oscache, TreeCache).
Возможны комбинации этих подходов... но в целом как-то так обычно
Здравствуйте, ALER_PROG, Вы писали:
ALE>А есть какие-то альтернативные методы решения данной проблемы ? Скажем , если не использовать какие-либо источники данных... Скажем, просто, массив данных, который доступен всем пользователям....и т.п. То есть какие-то глобальные данные , которые не относятся к какому-либо источнику...Просто накапливаются в процессе работы и используются совместно...
Здравствуйте, ALER_PROG, Вы писали:
ALE>А есть какие-то альтернативные методы решения данной проблемы ? Скажем , если не использовать какие-либо источники данных... Скажем, просто, массив данных, который доступен всем пользователям....и т.п. То есть какие-то глобальные данные , которые не относятся к какому-либо источнику...Просто накапливаются в процессе работы и используются совместно...
Вообще можно сделать обычный синглтон. Однако вам прийдется думать о том, что же делать когда таких данных станет очень много, или например, насколько они актуальны. Ведь в базе что-то может поменяться.
Здравствуйте, aka50, Вы писали:
A>Возможны комбинации этих подходов... но в целом как-то так обычно
В качестве клиента — тонкий клиент (обычный веб-браузер)... Как взаимодействуют : клиент — Сервлет — EJB — JDBC — MSSQLServer (собственно, 5-звенная структура, заложенная самой платформой). Изучая возможности EJB на первых порах, думал, что они способны осуществлять хранение данных как в источнике данных , так и в самом контейнере... Вот сейчас и пытаюсь решить такую проблему, поскольку EJB , я так понял, на такое не способны... или может я ошибаюсь ?
Здравствуйте, ALER_PROG, Вы писали:
ALE>В качестве клиента — тонкий клиент (обычный веб-браузер)... Как взаимодействуют : клиент — Сервлет — EJB — JDBC — MSSQLServer (собственно, 5-звенная структура, заложенная самой платформой). Изучая возможности EJB на первых порах, думал, что они способны осуществлять хранение данных как в источнике данных , так и в самом контейнере... Вот сейчас и пытаюсь решить такую проблему, поскольку EJB , я так понял, на такое не способны... или может я ошибаюсь ?
Это зависит от ejb контейнера, как это конфигурировать, но например в случае jboss, в качестве persistance используется hibernate,
а следовательно достаточно просто сконфигурировать кеш второго уровня (при чем любой, не обязательно распределенный), т.е.
ehcache вполне подойдет.
Здравствуйте, LDimas, Вы писали:
LD>Здравствуйте, ALER_PROG, Вы писали:
ALE>>А есть какие-то альтернативные методы решения данной проблемы ? Скажем , если не использовать какие-либо источники данных... Скажем, просто, массив данных, который доступен всем пользователям....и т.п. То есть какие-то глобальные данные , которые не относятся к какому-либо источнику...Просто накапливаются в процессе работы и используются совместно...
LD>Вообще можно сделать обычный синглтон. Однако вам прийдется думать о том, что же делать когда таких данных станет очень много, или например, насколько они актуальны. Ведь в базе что-то может поменяться.
Вопрос в другом: КАК и ГДЕ этот объект будет жить ??? Ни один из видов EJB не подпадает под такие условия жизни.(BMP и CMP завязаны с источником данных, SFSB — доступен только в рамках сессии ОДНОГО клиента, SLSB — не предназначен вообще для хранения каких-либо данных) ??
Здравствуйте, ALER_PROG, Вы писали:
ALE>В качестве клиента — тонкий клиент (обычный веб-браузер)... Как взаимодействуют : клиент — Сервлет — EJB — JDBC — MSSQLServer (собственно, 5-звенная структура, заложенная самой платформой). Изучая возможности EJB на первых порах, думал, что они способны осуществлять хранение данных как в источнике данных , так и в самом контейнере... Вот сейчас и пытаюсь решить такую проблему, поскольку EJB , я так понял, на такое не способны... или может я ошибаюсь ?
Какая версия EJB (2 или 3)?
Может между Сервлет и EJB вставить прослойку, которая будет кэшировать данные?
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, ALER_PROG, Вы писали:
ALE>>В качестве клиента — тонкий клиент (обычный веб-браузер)... Как взаимодействуют : клиент — Сервлет — EJB — JDBC — MSSQLServer (собственно, 5-звенная структура, заложенная самой платформой). Изучая возможности EJB на первых порах, думал, что они способны осуществлять хранение данных как в источнике данных , так и в самом контейнере... Вот сейчас и пытаюсь решить такую проблему, поскольку EJB , я так понял, на такое не способны... или может я ошибаюсь ?
A>Ну и читать как настраивается это ehcache A>http://ehcache.sourceforge.net/documentation/index.html
Увлекся ejb3 .
Тогда просто почитать про ehcache. Ибо он ни к чему не привязан,
но придется делать руками.
Можно подумать на счет облегчения себе жизни и использовать
iBatis. Работает с кешем замечательно, при этом поддерживает
сброс кеша по определенным командам или по времени...
В вашем случае инициализировать кеш придется самостоятельно...
Здравствуйте, Michael_Y, Вы писали:
M_Y>Здравствуйте, ALER_PROG, Вы писали:
ALE>>В качестве клиента — тонкий клиент (обычный веб-браузер)... Как взаимодействуют : клиент — Сервлет — EJB — JDBC — MSSQLServer (собственно, 5-звенная структура, заложенная самой платформой). Изучая возможности EJB на первых порах, думал, что они способны осуществлять хранение данных как в источнике данных , так и в самом контейнере... Вот сейчас и пытаюсь решить такую проблему, поскольку EJB , я так понял, на такое не способны... или может я ошибаюсь ?
M_Y> Какая версия EJB (2 или 3)? M_Y> Может между Сервлет и EJB вставить прослойку, которая будет кэшировать данные?
EJB 2.0. А какую прослойку например ? Вообще, в качестве такого объекта кэширования я первоначально думал использовать сервлет, так как он не уничтожается сервером по окончанию выполнения работы, а время жизни можно устанвоить в настройках веб-сервера...Однако, в этом случае, получится ли передать указатель на эти данные в EJB ? ...думаю, можно попробовать...
Здравствуйте, ALER_PROG, Вы писали:
ALE>Такую проблему никак не могу решить...
все советы этой ветки воспринимай через критическую призму кластеризации своих ejb, т.е. раз у тебя там и MSSQL и такая нагрузка, что хочется кэшировать, то наверняка до кластера вы дойдете быстро
просто не все варианты кэшей (как имеющихся, как и потенциально реализуемых) годятся для кластеров
ALE>как осуществить такое кэширование ? (планировал сделать это с помощью EJB, но , пока не нашёл решение данной проблемы...)
кэш — это обычные java-объекты в памяти JVM
самый простой вариант — какая-то структура данных, статически доступная из класса реализации SLSB, который предоставляет доступ к этим данным клиенту. по спеке иметь статические поля как бы нельзя, но только потому что неаккуратное обращение с ними приведет к проблемам. если же делать аккуратно, то все будет ok (главное не переборщить с размером кэша, все-таки для контейнера может оказаться неприятным открытием, что кто-то внтури него бесконтрольно отжирает память)
Здравствуйте, ALER_PROG, Вы писали:
ALE>>>В качестве клиента — тонкий клиент (обычный веб-браузер)... Как взаимодействуют : клиент — Сервлет — EJB — JDBC — MSSQLServer (собственно, 5-звенная структура, заложенная самой платформой). Изучая возможности EJB на первых порах, думал, что они способны осуществлять хранение данных как в источнике данных , так и в самом контейнере... Вот сейчас и пытаюсь решить такую проблему, поскольку EJB , я так понял, на такое не способны... или может я ошибаюсь ?
M_Y>> Какая версия EJB (2 или 3)? M_Y>> Может между Сервлет и EJB вставить прослойку, которая будет кэшировать данные? ALE>EJB 2.0. А какую прослойку например ? Вообще, в качестве такого объекта кэширования я первоначально думал использовать сервлет, так как он не уничтожается сервером по окончанию выполнения работы, а время жизни можно устанвоить в настройках веб-сервера...Однако, в этом случае, получится ли передать указатель на эти данные в EJB ? ...думаю, можно попробовать...
Как у вас происходит получение данных? Через Entity EJB?
Если EJB у вас — это Entity EJB, то можно прямо в EJB запихнуть логику работы с кэшем. Если нет, то надо писать свою прослойку — классы, через которые происходит получение/вставка/изменение данных и которые реализуют логику раоты с кэшем (проверяют наличие данных в кэше, если их нет, вытягивают из базы и прочее), т.е. DAO (если я правильно понимаю ).
Здравствуйте, Michael_Y, Вы писали:
M_Y> Как у вас происходит получение данных? Через Entity EJB? M_Y> Если EJB у вас — это Entity EJB, то можно прямо в EJB запихнуть логику работы с кэшем. Если нет, то надо писать свою прослойку — классы, через которые происходит получение/вставка/изменение данных и которые реализуют логику раоты с кэшем (проверяют наличие данных в кэше, если их нет, вытягивают из базы и прочее), т.е. DAO (если я правильно понимаю ).
возможно я не совсем понимаю... сам Entity EJB связан напрямую с источником данных. Под кэшированием в данном случае я понимаю некий объект, существующий в оперативной памяти (RAM) контейнера ПОСТОЯННО , или , покрайней мере, его существование может управляться.... Возникает вопрос: каким образом CMP или BMP может обеспечить существование такого объекта ?
Здравствуйте, ALER_PROG, Вы писали:
M_Y>> Как у вас происходит получение данных? Через Entity EJB? M_Y>> Если EJB у вас — это Entity EJB, то можно прямо в EJB запихнуть логику работы с кэшем. Если нет, то надо писать свою прослойку — классы, через которые происходит получение/вставка/изменение данных и которые реализуют логику раоты с кэшем (проверяют наличие данных в кэше, если их нет, вытягивают из базы и прочее), т.е. DAO (если я правильно понимаю ). ALE>возможно я не совсем понимаю... сам Entity EJB связан напрямую с источником данных. Под кэшированием в данном случае я понимаю некий объект, существующий в оперативной памяти (RAM) контейнера ПОСТОЯННО , или , покрайней мере, его существование может управляться.... Возникает вопрос: каким образом CMP или BMP может обеспечить существование такого объекта ?
Может и я чего не понимаю, т.к. с Entity EJB практически не работал.
Введем определения:
DTO (Data Transfer Object) — содержит данные (из базы), в простейшем случае — класс из набора public полей.
DAO (Data Access Object) — реализация CRUD операций для DTO.
В твоем случае EJB выступает как смесь DTO и DAO (если я правильно понимаю).
Операции CRUD в Entity EJB реализуются методами ejbLoad, ejbStore, ejbRemove. Тебе достаточно будет добавить в
эти методы проверку наличия DTO (ассоциированного с данным экземпляром Entity EJB) в кэше. Ну и удалять/изменять его в кэше при удалении/изменении. Т.е. тебе надо выделить из твоих Entity EJB классы идентификаторов (primary key) и соственно DTO.
Если я где ошибся или неправильно понимаю работу Entity EJB, буду рад критике более опытных коллег .
.
).
