Sunday, December 3, 2017

OpenJpa query caching is not refreshing in case of null value - How to resolve this issue?

Solution:

So far it is not fixed yet. But they have given some bypassing solution.
  1. Disable query cache
To disable the query cache (default), set the openjpa.QueryCache property to false:
<property name="openjpa.QueryCache" value="false"/>
  1. By configuring sql query cache to false
    • To specify a custom cache class:
      <property name="openjpa.jdbc.QuerySQLCache" value="com.mycompany.MyCustomCache"/>
    • To use an unmanaged cache:
      <property name="openjpa.jdbc.QuerySQLCache" value="false"/>
    OR
    • To use an unmanaged cache:
      <property name="openjpa.jdbc.QuerySQLCache" value="all"/>

  1. Open JPA - L2 Cache Issue and Workaround
This tutorial depicts your problem same to same. Here you can get the clear conception of occuring this error.
It gives a solution that you must have to keep related data. So that NullPointerException will not arise. Data must be consistent until OpenJPA not solve the issue. :D

  1. Several mechanisms are available to the application to bypass SQL caching for a JPQL query.
A user application can disable Prepared SQL Cache for entire lifetime of a persistence context by invoking the following method on OpenJPA's EntityManager SPI interface:
OpenJPAEntityManagerSPI.setQuerySQLCache(boolean) 
  1. Plug-in property openjpa.jdbc.QuerySQLCache can be configured to exclude certain JPQL queries as shown below.
    <property name="openjpa.jdbc.QuerySQLCache" value="true(excludes='select c from Company c;select d from Department d')"/>
will never cache JPQL queries select c from Company c and select d from Department d.

Root Cause Analysis:

The query cache stores the object IDs that are returned by query executions. When you run a query, JPA assembles a key that is based on the query properties and the parameters that are used at launch time and checks for a cached query result. If one is found, the object IDs in the cached result are looked up, and the resulting persistence-capable objects are returned. Otherwise, the query is launched against the database and the object IDs that are loaded by the query are placed into the cache. The object ID list is not cached until the list that is returned at query launch time is fully traversed.

IBM Recommendation:

L2 caching increases the memory consumption of the application, therefore, it is important to limit the size of the L2 cache. There is also a possibility of stale data for updated objects in a clustered environment. Configure L2 caching for read-mostly, infrequently modified entities. L2 caches are not recommended for frequently and concurrently updated entities.

Resource Link:



No comments:

Post a Comment