PI97686: OPENJPA QUERY CACHE MISS RESULTS IN CLASSCASTEXCEPTION

9.0.0.9: WebSphere Application Server traditional V9.0 Fix Pack 9
9.0.0.10: WebSphere Application Server traditional V9.0 Fix Pack 10
8.5.5.15: WebSphere Application Server V8.5.5 Fix Pack 15
9.0.0.11: WebSphere Application Server traditional V9.0 Fix Pack 11
9.0.5.0: WebSphere Application Server traditional Version 9.0.5 Refresh Pack
9.0.5.1: WebSphere Application Server traditional Version 9.0.5 Fix Pack 1
9.0.5.2: WebSphere Application Server traditional Version 9.0.5 Fix Pack 2
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
9.0.5.3: WebSphere Application Server traditional Version 9.0.5 Fix Pack 3
8.5.5.20: WebSphere Application Server V8.5.5.20
8.5.5.18: WebSphere Application Server V8.5.5 Fix Pack 18
8.5.5.19: WebSphere Application Server V8.5.5 Fix Pack 19
8.5.5.16: WebSphere Application Server V8.5.5 Fix Pack 16
8.5.5.21: WebSphere Application Server V8.5.5.21

APAR status

• Closed as program error.

Error description

• The investigation and proposed fix to OpenJPA has been
  documented in this OpenJPA JIRA:
  https://issues.apache.org/jira/browse/OPENJPA-2646.
  
  The issue comes down to a VERY narrow race condition that
  occurs in OpenJPA's cache overflow swapping. OpenJPA maintains
  a query cache that consists of a "hard" cache map with a
  default size of 1000 (this is not configurable) and a "soft"
  cache map. When the hard cache map reaches the max size,
  OpenJPA starts evicting random entries into the soft cache to
  maintain the hard cache size limit. During this migration,
  there exists a very small moment in time were the random entry
  has been removed from the hard cache and has not yet been
  entered into the soft cache. This alone would not be a big
  issue for OpenJPA, except further investigation showed that
  OpenJPA was not using proper synchronization. This allowed
  dirty reads of the cache to occur, resulting in seemingly
  random cache misses.
  
  The CCE the customer is experiencing stemmed from OpenJPA
  "seeing" the query entry in the cache, but upon reading the
  value, returning a null result. That code path, at the wrong
  read time, resulted in OpenJPA missing a "re-parameterization"
  section of code to prevent java.lang.String values from being
  used.
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server                                      *
  ****************************************************************
  * PROBLEM DESCRIPTION: While executing queries in              *
  *                      batch, a sporadic ClassCastException    *
  *                      can occur when QuerySQLCache is         *
  *                      enabled                                 *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  With OpenJPA's QuerySQLCache enabled, there exists the
  possibility for a random exception to occur while executing a
  query. This will only occur in a multi-threaded environment,
  most likely while running many queries in batch. Please read
  https://issues.apache.org/jira/browse/OPENJPA-2646 for a more
  indepth explanation of the issue if you believe this is an
  exception you are seeing.
  Exception:
  Caused by: java.lang.ClassCastException: java.lang.String
  incompatible with java.lang.Integer
  at
  org.apache.openjpa.jdbc.kernel.PreparedSQLStoreQuery$PreparedSQL
  Executor.toParameterArray(PreparedSQLStoreQuery.java:160)
  at
  org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:857)
  

Problem conclusion

• The fix for this APAR changes the OpenJPA implementation and
  involves an update to the OpenJPA thirdparty bundle. See
  https://issues.apache.org/jira/browse/OPENJPA-2646
  
  The fix for this APAR is currently targeted for inclusion in
  Service Level (Fix Pack) 9.0.0.9 of WebSphere Application
  Server version 9.0, Service Level (Fix Pack) 8.5.5.15 of
  WebSphere Application Server version 8.5, and in fix pack
  18.0.0.3 for WebSphere Application Server Liberty. Please
  refer to the Recommended Updates page for delivery information:
  http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  WEBS APP SERV N

• Fixed component ID

  5724H8800

Applicable component levels

• R850 PSY

     UP

• R900 PSY

     UP