Configuration of Level 1 and Level 2 cache in JPA

Question

I have read the following pages and I have several doubts.

About the persistence context type for Level 1 cache What is the difference between Transaction-scoped Persistence context and Extended Persistence context?

About the Level 2 cache http://www.objectdb.com/java/jpa/persistence/cache

Now, my questions are:

1. In a normal situation what is the best PersistenceContextType to choose for L1 cache, TRANSACTION or EXTENDED? I suppose the answer is TRANSACTION as it is the default. However I would like to know when should I use EXTENDED.
2. In a normal situation what are the best values to choose for the following porperties of L2 cache?:
   • javax.persistence.sharedCache.mode (I suppose the answer is ALL as it is the default and caches all the entities)
   • javax.persistence.cache.retrieveMode (I suppose the answer is USE as it is the default and uses the cache on retrieval)
   • javax.persistence.cache.storeMode (I suppose the answer is USE as it is the default, however I still don't understand the difference with REFRESH which seems better for me)

Can someone explain how to correctly put these properties of L1 and L2 correctly and explain when to use some values or others?

Answer 1

NOTE: this answer is not yet complete, I will update with details WRT cache modes

When working with Java EE, the default persistence context (PC) setting is TRANSACTION. This is also the optimal mode for almost all tasks. Because of it's relatively short lifespan, it has the benefit of being low or zero maintenance.

I can think of primarily two reasons to prefer an extended EM over a transactional one:

• communication with external systems or the UI. You can manipulate managed entities and save them with the least possible moving parts - no merging and even no explicit saving is necessary. See this example by Adam Bien.

• mimicking a conversation scope - using a single transaction spanning multiple HTTP requests is not practical, so an extended PC can be used instead. Examples here and here

• an application where data is rarely written, but read very frequently. If you have reason to believe that the data is not going to change, you can have the benefits of caching the entities for frequent reads instead of fetching them from DB each time.

There are some downsides to using an extended EM

• if a transaction is rolled back, all managed entities are detached. Restoring the PC to a consistent usable state may be quite hard to accomplish.

• when used without caution, an extended PC can get cluttered with entities you no longer need. A long-living cache can contain large amounts of stale data.

• You may need a strategy for refreshing/refetching the managed entities and a strategy for evicting entities, classes or clearing the cache altogether. Failure to design appropriate strategies can result in bugs that hard to spot and harder to reproduce. Proper cache invalidation is not trivial

So if using an extended EM, use it for a single purpose, so you can reason about the contents of the cache more easily.

I am not sure about the appropriate storeMode and retrieveMode settings yet. As for the storeMode, I have some doubts about their exact function