Конфигурация кэша уровня 1 и уровня 2 в JPA

Question

Я прочитал следующие страницы, и у меня есть несколько сомнений.

О типе персистентного контекста для кэша уровня 1 В чем разница между контекстом персистентности в области транзакций и контекстом расширенного персистентности?

О кеше 2-го уровня http://www.objectdb.com/java/jpa/persistence/cache

Теперь мои вопросы:

1. В обычной ситуации, какой лучший PersistenceContextType выбрать для кэша L1, TRANSACTION или EXTENDED? Я предполагаю, что ответ - СДЕЛКА, поскольку это по умолчанию. Однако я хотел бы знать, когда я должен использовать EXTENDED.
2. В нормальной ситуации, какие значения лучше выбрать для следующих характеристик кэша L2?:
   • javax.persistence.sharedCache.mode (я полагаю, ответ - ВСЕ, так как он используется по умолчанию и кэширует все объекты)
   • javax.persistence.cache.retrieveMode (я полагаю, ответ будет USE, так как он используется по умолчанию и использует кеш при поиске)
   • javax.persistence.cache.storeMode (я полагаю, что ответ будет USE, так как это значение по умолчанию, однако я все еще не понимаю разницу с REFRESH, которая кажется мне лучше)

Может кто-нибудь объяснить, как правильно выставить эти свойства L1 и L2, и объяснить, когда использовать некоторые значения или другие?

Answer 1

ПРИМЕЧАНИЕ: этот ответ еще не завершен, я буду обновлять с деталями режимы кеша WRT

При работе с Java EE настройка персистентного контекста (ПК) по умолчанию TRANSACTION, Это также оптимальный режим для почти всех задач. Из-за его относительно короткого срока службы преимущество заключается в том, что он требует минимального технического обслуживания или не требует обслуживания.

Я могу думать в первую очередь о двух причинах, чтобы предпочесть расширенный EM над транзакционным:

• связь с внешними системами или пользовательским интерфейсом. Вы можете манипулировать управляемыми объектами и сохранять их с наименьшими возможными движущимися частями - без слияния и даже без явного сохранения не требуется. Посмотрите этот пример Адамом Бьеном.

• имитация области диалога - использование одной транзакции, охватывающей несколько HTTP-запросов, нецелесообразно, поэтому вместо нее можно использовать расширенный ПК. Примеры здесь и здесь

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

Есть некоторые недостатки использования расширенного EM

• если транзакция откатывается, все управляемые объекты отключаются. Восстановление ПК в согласованном рабочем состоянии может быть довольно сложным.

• при использовании без предупреждения расширенный ПК может быть загроможден объектами, которые вам больше не нужны. Долгоживущий кэш может содержать большие объемы устаревших данных.

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

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

Я не уверен насчет подходящего storeMode а также retrieveMode настроек пока нет. Что касается storeMode, у меня есть некоторые сомнения по поводу их точной функции