PM76095: SLOW EJB 3.0 PERFORMANCE WHEN A SQL QUERY CONTAINS A PARAMETER MARKER (?)

APAR status

• Closed as program error.

Error description

• In EJB 3.0, a SQL query may contain a parameter marker (?)
  similar to the following:
  
  t0.code = ?
  
  This can result in slower performance when compared with the
  following EJB 2.1 SQL query which uses a defined literal:
  
  t0.code = 'Y'
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server V6.1.0 Feature Pack for Enterprise   *
  *                  JavaBeans 3.0 who make use of JPA queries   *
  *                  which contain a literal.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Performance considerations when         *
  *                      paramerter markers are used in place    *
  *                      of literals.                            *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Take the following entity:
  public class MyEntity implements Serializable {
  @Id
  private String pk;
  private String code;
  .........
  Using this entity, take this query:
  Query q = em.createQuery("SELECT f FROM MyEntity f WHERE
  f.code = 'y'");
  MyEntity me = (MyEntity) q.getSingleResult();
  Executing this query would result in this SQL:
  SELECT t0.pk, t0.code FROM MyEntity t0 WHERE (t0.code = ?)
  [params=(String) y]
  As can be seen by the SQL generated, the literal, 'y' in this
  case, has been turned into a parameter marker ('?').  In most
  cases using a parameter marker is far more efficient and
  offers overall performance gains (e.g. it has the advantage of
  query statement caching).  However, there are cases where the
  user may intend for the literal to be used, rather than a
  parameter marker.
  

Problem conclusion

• This APAR will provide a query hint to by-pass setting
  literals as parameters; rather OpenJPA will generate the
  literal in-line into the generated SQL statement.
  
  To apply the query hint the 'setHint' method on the Query will
  need to be invoked with a hint of
  "openjpa.hint.UseLiteralInSQL" set to true.  As an example,
  the above code will need to be run as follows:
  
  Query q = em.createQuery("SELECT f FROM MyEntity f WHERE
  f.code = 'y'");
  
  q.setHint("openjpa.hint.UseLiteralInSQL", "true");
  
  MyEntity me = (MyEntity) q.getSingleResult();
  
  With this hint, the following SQL will be generated:
  
  SELECT t0.pk, t0.code FROM MyEntity t0 WHERE (t0.code = 'y')
  
  
  By using this hint however, one must consider the potential
  negative impacts of using literals rather than parameter
  markers in SQL.  That is, one must consider the caching of
  Prepared SQL statements in OpenJPA (i.e.  the prepared
  SQLCache is the OpenJPA cache for the SQL that it generates
  during its processing; more on this in a moment), and possibly
  Prepared Statement caching at the WebSphere, RRA, or DB level.
   At least for OpenJPA, the reason the literal is parameterized
  is to allow the SQL to be cached.  If it is not parameterized,
  it can't be cached.  An explanation of this statement can be
  found in the 'Prepared SQL Cache' topic in the following
  OpenJPA manual:
  
  http://openjpa.apache.org/builds/latest/docs/docbook/manual.html
  #ref_guide_cache_querysql
  
  This section talks about the use of a Prepared SQL cache, and
  in particular examples 10.23 and 10.24 demonstrate why a
  statement with hard coded values can't be cached, and why a
  parameterized statement can be cached.
  
  The fix for this APAR is currently targeted for inclusion
  in Enterprise JavaBeans 3.0 Feature Pack Fix Pack 47
  (6.1.0.47) of WebSphere Application Server version
  6.1.0.
  
  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:

  PM81058

Fix information

• Fixed component name

  WAS EJB3 FEATUR

• Fixed component ID

  5724J0851

Applicable component levels

• R610 PSY

     UP