Является ли JPA + EJB слишком медленным (или тяжелым) для транзакций через Интернет? - PullRequest
Новая
       11

Является ли JPA + EJB слишком медленным (или тяжелым) для транзакций через Интернет?

4 голосов
/ 21 апреля 2010

Я занимаюсь разработкой автономного клиентского приложения Java, которое подключается к приложению Glassfish v3 для транзакций в стиле фасада JPA / EJB. Другими словами, мое клиентское приложение не подключается напрямую к базе данных в CRUD, но оно передает объекты JPA, используя сеансы EJB без сохранения состояния.

У меня есть сценарии, в которых это клиентское приложение будет использоваться во внешней сети, подключенной через VPN через Интернет с клиентским подключением 512 кбит / с / DSL, и простой запрос занимает так много времени, я вижу график трафика и когда Я объединяю сущность в клиентском приложении и вижу мегабайты трафика (я не мог поверить, как сущность заказа на покупку может весить более 1 МБ).

У меня LAZY выборка почти во всех отношениях «многие ко многим», но у меня много отношений «многие к одному» между сущностями (но это большое преимущество JPA!).

Могу ли я сделать что-нибудь, чтобы ускорить скорость транзакций между JPA / EJB-сервером и удаленным Java-клиентом?

Заранее спасибо.

Ответы [ 4 ]

1 голос
/ 21 апреля 2010

Я вижу график трафика и когда Я объединяю сущность в клиенте приложение вижу мегабайты трафика (Я не мог поверить, как покупка объект заказа может весить более 1 мб).

RMI-IIOP немного более многословен, чем обычный RMI. По моему опыту, это не работает хорошо при передаче больших графиков.

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

Могу ли я сделать что-то, чтобы ускорить скорость транзакций между JPA / EJB-сервер и удаленный Java клиент

Но суть проблемы в том, что вы находитесь в сценарии, когда вам нужно подумать о стратегии передачи данных. Вы должны разработать свое приложение так, чтобы вы не отправляли большие графики; эта проблема должна быть учтена при разработке вашего приложения. Затем вы можете решить отправлять объекты JPA или полагаться на объект передачи данных (DTO).

Вы могли бы также рассмотреть возможность использования расширенного контекста персистентности с сессионным компонентом с сохранением состояния, таким образом, я думаю, что объект на стороне клиента все еще может загружаться лениво. Но я никогда не использовал это лично и не знаю, хорошо ли это работает или нет.

1 голос
/ 21 апреля 2010

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

Вы можете попробовать сериализовать объект, который вы отправляете на сервер, в файл (используя стандартный ObjectOutputStrem) и проверить размер файла.

0 голосов
/ 22 апреля 2010

Могу ли я сделать что-нибудь, чтобы ускорить скорость транзакций между JPA / EJB-сервером и удаленным Java-клиентом?

Вы не можете ускорить вещи. Однако вы можете передавать меньше (только необходимые детали или более легкие предметы).

0 голосов
/ 21 апреля 2010

Если я правильно понимаю вашу архитектуру, у вас есть: 

 Client(works with disconnected Entities)  
            ----RMI/IIOP--->
 Server(SLSB, using entitiy manager, JPA persistence) 
            ----JDBC------->
 Database

В действительности ваши SLSB выражают свой интерфейс в терминах объектов JPA, ваши DTO - это объекты JPA. Я вижу два возможных сценария:

  1. вашему клиенту требуется только подмножество данных в ваших объектах JPA, и вы переносите больше, чем нужно на самом деле. Например, вам может понадобиться только имя сотрудника, и вы отправляете всю его историю жизни.
  2. вы пересекаете больше дерева отношений, чем намереваетесь

У меня такое ощущение, что сначала вы должны точно определить, что вы получаете от клиента. Должно быть довольно легко добавить несколько операторов трассировки, чтобы точно увидеть, какие данные у вас есть.

Возможно, настроив ленивую загрузку и т. Д., Вы сможете контролировать поведение.

Я ожидаю, что вам может понадобиться определить клиентские DTO «подмножества» и заставить ваш SLSB действовать как фасад, отправляя только данные подмножества. Это больше работы, но у вас есть прекрасный контроль над тем, что в интерфейсе.

Архитектурно, точная настройка удаленного интерфейса - вполне разумная вещь, которую нужно сделать.

...