Solution:
So far it is not fixed yet. But they have given some bypassing solution.
- Disable query cache
To disable the query cache (default), set the
openjpa.QueryCache
property to false:<property name="openjpa.QueryCache" value="false"/>
- 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"/>
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
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)
- 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.
No comments:
Post a Comment