JPA Caching

The following two tabs change content below.
Prasad Kharkar is a java enthusiast and always keen to explore and learn java technologies. He is SCJP,OCPWCD, OCEJPAD and aspires to be java architect.

Latest posts by Prasad Kharkar (see all)

Let us understand how jpa caching method is divided in different layers.

JPA Caching:

Although JPA Caching includes two levels, i.e. Persistence context and shared level, roughly an application can have different levels. Let us understand the diagram which I’ve drawn quite similar to the one in Apress : Mastering Java Persistence API 2.0 book.

JPA Caching
JPA Caching

Application Level:

Though application level cannot be considered as a real level of JPA caching, we can write some applications such that they hold references to jpa entities. These entities can become stale as they will be placed in application level.

Persistence Context level:

This jpa caching level is the first real caching level. It is the first level from which a persistence provider can retrieve entities from memory and within transaction boundaries. Cached entities are not available when a transaction completes. In case of extended persistence contexts, the cache is unavailable after transaction is closed.

Shared Cache level:

JPA Caching in EntityManagerFactory is the real second level cache  JPA provides. Cached entities from EntityManagerFactory are shared across all entitymanagers and hence the name shared cache.

JDBC Cache level:

This isn’t also a real JPA caching level. JDBC drivers can cache connections and statements. Some drivers can track tables and columns.

Let us understand what happens when a find operation is performed for entity.

  • ¬†Application from which find method is called looks in its local cache for vehicle with id = 1. It if doesn’t find, it issues the call on entity manager.
  • EntityManager checks for vehicle in its persistence context. This is the first real jpa caching level. If it is available in persistence context, it is returned otherwise, entity is searched in shared cache.
  • If the entity is present in shared cache, an instance is created and put in persistence context level cache.
  • If entity is not present in shared cache also, sql query is generated to select the entity row from database. The query result is used to create an object and it is passed back to shared cache.
  • This newly created instance is put into shared cache and a new copy of the same instance is put into persistence context level cache where it becomes managed by entity manager.

 

References for further study :

Share Button

Prasad Kharkar

Prasad Kharkar is a java enthusiast and always keen to explore and learn java technologies. He is SCJP,OCPWCD, OCEJPAD and aspires to be java architect.

5 thoughts on “JPA Caching

  • September 5, 2014 at 5:09 pm
    Permalink

    Question asked by my friend :
    I have a string that looks like this:
    0,0,1,2,4,5,3,4,6
    What I want returned is a string[] that was split after every 3rd comma, so it would look like this:
    [ “0,0,1”, “2,4,5”, “3,4,6” ]
    I have found similiar functions but they all don’t split with the nth amount of commas.
    You can try to use split method with (?<=\\G\\d+,\\d+,\\d+), regex

    Reply
  • Pingback:JPA Caching Example | theJavaGeek

  • February 19, 2016 at 6:25 am
    Permalink

    I don’t think stored preocdures are the way to go. Keep the logic all in one place, the (OO) code. A lot has been written about this and the arguments against stored preocdures are very compelling.An exception might be when the design is centered around the database rather than the domain model or the UI. However, I can’t think of many situations where that would be a good way to go. Perhaps if it’s a legacy database or the app is expected to have an extremely long lifespan, likely outliving the programming language or even OOD.

    Reply
  • March 29, 2016 at 3:23 pm
    Permalink

    Thank You For This Simple explanition

    Reply
  • November 3, 2016 at 5:21 am
    Permalink

    Employee table has emp_id, first_name and last_name. How to use em.find() based on the first_name and last_name (unique columns and not primary key column ’emp_id’) ?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *