Когда EntityManager JPA дает преимущества производительности по сравнению с простым JDBC?

Question

Я работаю над приложением базы данных для клиента. Старый код приложения совершенно несовместим с тем, как он обращается к базе данных; в некоторых методах он использует объекты Hibernate, в других он напрямую создает подключения JDBC и использует чистый SQL, в некоторых он создает соединения Hibernate и использует их для соединения JDBC. В любом случае мы собираемся перестроить много кода, чтобы сделать его согласованным. Наш клиент услышал о JPA и попросил нас использовать его, потому что клиент полагает, что он будет иметь преимущество в производительности.

Проблема в том, что мое понимание преимуществ производительности от JPA заключается в том, что большая польза от EntityManager от JPA, поскольку она позволяет вам сохранять объекты в памяти между вызовами базы данных. Однако приложение, над которым мы работаем, не будет единственным приложением, обращающимся к базе данных, и будет работать в нескольких экземплярах в нескольких местах. Кроме того, EntityManagers aren't thread-safe, чтобы мы не смогли увидеть измененные данные в другой части того же приложения. Таким образом, похоже, что нам нужно будет получить новый EntityManager из EntityManagerFactory в каждом методе и закрыть его, когда метод будет завершен. Таким образом, мы не смогли бы долго сохранять объекты в памяти, потому что другим приложениям нужны данные, которые мы меняем. & измените нужные нам данные.

Текущий код - такой беспорядок, что переход к JPA в любом случае даст большие преимущества в ремонтопригодности и согласованности. Однако, если это не даст преимуществ производительности, мы должны сообщить клиенту как можно скорее, чтобы они не были разочарованы. Существуют ли другие способы, с помощью которых JPA обеспечивает преимущества в производительности, помимо очевидного, связанного с контекстами Persistance?

Я проверил другие вопросы в StackOverflow, но те, которые я нашел, говорят об изменениях в больших партиях (example here). Наш клиент хочет, чтобы изменения, сделанные одним приложением, были видимыми для других приложений как можно скорее, поэтому наше приложение сделает несколько небольших изменений, а не периодические изменения партии.

спасибо.

Answer 1

JPA не обязательно даст вам какое-либо преимущество в производительности над обычным JDBC. Это может иметь большие впечатления от вашей системы. Все зависит от того, как вы его используете.

Похоже, вы используете Hibernate уже. Сама JPA является спецификацией, которая реализуется рядом поставщиков или поставщиков. Hibernate является одним из них (и является поставщиком JPA2, который я использую на работе).

Создание EntityManagerFactory может занять некоторое время. С другой стороны, создание EntityManger является быстрым и легким.

Если вы испытываете плохую производительность, вы можете попробовать профилировать код, чтобы увидеть, где проблемы с производительностью.

Однако переход на один уровень доступа звучит как хорошая идея для меня, и это улучшает ремонтопригодность и согласованность.

Answer 2

JPA является стандартом для OR/M и существует множество причин использовать структуру ORM или продукт сохранения, и многие причины использовать JPA в частности.

Причины ОРМ

• Устраняет все «руки» отображение в Java из SQL ResultSet в Ява POJO значительно уменьшая количество картографических работ.
• Уменьшает объем работы, требуемой для базы кода постоянства, с изменением модели данных домена и/или реляционной модели данных.
• Использует большую библиотеку персистентности, чтобы избежать разработки решений для проблем, которые другие уже решили.
• Позволяет избежать низкого уровня JDBC и SQL-кода.
• Использует объектно-ориентированное программирование и использование объектной модели.
• Обеспечивает независимость базы данных и схемы.
• Большинство продуктов ORM являются бесплатными и с открытым исходным кодом.
• Многие корпоративные корпорации предоставляют поддержку и услуги для ORM .
• Предоставляет высокопроизводительные функции, такие как кеширование и оптимизация баз данных и запросов.

Причины JPA

• Это стандартная и часть EJB3 и Java EE.

• Много бесплатных и с открытым исходным кодом с поддержкой уровня предприятия.

• Переносимость между серверами приложений и продуктами непрерывности (позволяет избежать блокировки поставщика). Полезная и функциональная спецификация.

• Поддерживает как Java EE, так и Java SE.

ORM может быть горячей темой для некоторых людей, и есть много лагерей ORM. Есть те, которые поддерживают конкретный стандарт или продукт. Есть те, которые не верят в ORM или даже объекты вообще и предпочитают JDBC. Есть те, которые по-прежнему считают, что объектные базы данных - это путь. Лично я бы порекомендовал вам использовать любую технику, с которой вам больше всего нравится, но если вы никогда не использовали ORM или JPA, возможно, попробуйте и посмотрите, нравится ли вам это. В приведенном ниже списке представлены несколько дискуссий о том, почему или почему не использовать JPA и ORM. (Из Викиучебников)

Вот некоторые полезные linkes: JPA or JDBC, how are they different? , Java Persistence/Why use JPA or ORM?, JPA is great but damned slow