Какой метод в BMP используется, чтобы избежать ненужных обращений к базе данных?

Question

Если я использую bean-компонент BMP, есть ли способ, который позволяет избежать ненужных обращений к базе данных и повысить эффективность ...

Любой из этих методов служит цели? (Вопрос в сертификационном тесте) ejbSave (), ejbStore () или ejbPersist ()

В многоуровневой архитектуре с базой данных, сервером приложений и веб-уровнями вы оптимизируете производительность за счет сокращения сетевого трафика «туда-обратно». Говорят, что лучшим подходом является запуск и остановка транзакций на уровне сервера приложений в контейнере EJB. Поэтому хотелось бы знать, что методы помогают сократить ненужные обходы для этого в bean-управляемых bean-компонентах типа персистентности .... Я новичок в ejb .., поэтому я пытаюсь изучить концепции

ejbSave () и ejbpersist () не существуют ...

Answer 1

Вам не придется иметь дело ни с одним из этих методов: 'ejbSave (), ejbStore () или ejbPersist ()'

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

Краткий ответ:

Да, методы EntityManager

Длинный ответ:

Чтобы избежать сетевых обращений к базе данных, вам просто нужно правильно установить границы транзакций.Когда вы используете методы, предоставляемые EntityManager (я говорю о JPA), методы действуют в контексте постоянства.Контекст постоянства, являющийся кешем, избегает реальных попаданий в БД, пока не произойдет фиксация.

---

Ниже приведен раздел из TomEE docs

JPA101

Если вам нужно понять одну вещь, чтобы успешно использовать JPA (Java Persistence API), это концепция Cache .Почти все сводится к кешу в тот или иной момент.К сожалению, кэш-память - это внутренняя вещь, которая не раскрывается через классы API JPA, поэтому с точки зрения кодирования ее нелегко потрогать или почувствовать.

Вот краткая шпаргалка мира JPA:

• A Кэш является копией данных , то есть копией, полученной из базы данных, но находящейся вне ее.
  • Сброс a Кэш - это процесс помещения измененных данных обратно в базу данных.
  • A PersistenceContext по сути является Cache.Он также имеет тенденцию иметь свое собственное подключение к базе данных без общего доступа.
  • EntityManager представляет собой PersistenceContext (и, следовательно, Cache)
  • EntityManagerFactory создает EntityManager (и, следовательно, PersistenceContext / Cache)
  • С вы несете ответственность за создание и отслеживание EntityManager (PersistenceContext / Cache) ... - Вы must используйте EntityManagerFactory для получения EntityManager - Полученный EntityManager экземпляр равен PersistenceContext / Cache - EntityManagerFactory может быть введен через @ PersistenceUnit только аннотация (не @PersistenceContext) - Вам не разрешено использовать @PersistenceContext для ссылки на единицу типа RESOURCE_LOCAL - Вы должны используйте API EntityTransaction , чтобы начать / зафиксировать около каждого вызова вашего EntityManger - Вызов entityManagerFactory.createEntityManager() дважды приводит к двум отдельным экземплярам EntityManager и, следовательно, двум отдельным постоянным константам / кэшам.- Это почти никогда хорошая идея иметь более одного экземпляра используемого EntityManager (не создавайте второй, если вы не уничтожили первый)
  • С контейнером выполнит создание и отслеживание EntityManager (PersistenceContext / Cache) ... - Вы не можете использовать EntityManagerFactory для получения EntityManager- Вы можете получить только EntityManager , предоставляемый контейнером - EntityManager может быть введен только с помощью аннотации @ PersistenceContext (not @PersistenceUnit) - Вам не разрешено использовать @PersistenceUnit для ссылки на единицу типа TRANSACTION - EntityManager , заданный контейнером, является ссылкой в PersistenceContext / Cache, связанный с транзакцией JTA.- Если транзакция JTA не выполняется, EntityManager нельзя использовать , поскольку отсутствует PersistenceContext / Cache.- Каждый, у кого ссылка EntityManager на один и тот же блок в одной и той же транзакции 1111 * автоматически получит ссылку на один и тот же PersistenceContext / Cache * - PersistenceContext / Cache очищено и очищено в JTA коммит время

Cache == PersistenceContext

Концепция кэша базы данных является чрезвычайно важной концепцией в курсе. Без копии данных в памяти (т.е. кеш), когда вы вызовите account.getBalance () поставщик персистентности должен будет прочитать значение из базы данных. Вызов account.getBalance () несколько раз приведет к нескольким поездкам в базу данных. Это, очевидно, будет большой трата ресурсов. Другая сторона наличия кеша в том, что при вызове account.setBalance (5000) также не попадает в базу данных (обычно). когда кэш «очищается», данные в нем отправляются в базу данных через столько SQL обновляет, вставляет и удаляет по мере необходимости. Это основы упорство java любого вида все обернуто в двух словах. Если ты можешь поймите, что вы можете использовать практически любые технологии настойчивости Ява должна предложить.

Осложнения могут возникнуть при наличии более одного PersistenceContext / Cache, относящиеся к одним и тем же данным в одной и той же транзакции. В любой транзакции требуется ровно один PersistenceContext / Cache для данный набор данных. Использование модуля TRANSACTION с EntityManager созданный контейнер всегда гарантирует, что это так. С модуль RESOURCE_LOCAL и EntityManagerFactory, которые вы должны создать и использовать ровно один экземпляр EntityManager в вашей транзакции, чтобы обеспечить только один активный PersistenceContext / Cache для данного набора активных данных против текущей транзакции.