IBM Support

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

Fixes are available

8.5.0.2: WebSphere Application Server V8.5 Fix Pack 2
8.0.0.6: WebSphere Application Server V8.0 Fix Pack 6
7.0.0.29: WebSphere Application Server V7.0 Fix Pack 29
8.0.0.7: WebSphere Application Server V8.0 Fix Pack 7
8.0.0.8: WebSphere Application Server V8.0 Fix Pack 8
7.0.0.31: WebSphere Application Server V7.0 Fix Pack 31
7.0.0.33: WebSphere Application Server V7.0 Fix Pack 33
8.0.0.9: WebSphere Application Server V8.0 Fix Pack 9
7.0.0.35: WebSphere Application Server V7.0 Fix Pack 35
8.0.0.10: WebSphere Application Server V8.0 Fix Pack 10
7.0.0.37: WebSphere Application Server V7.0 Fix Pack 37
8.0.0.11: WebSphere Application Server V8.0 Fix Pack 11
7.0.0.39: WebSphere Application Server V7.0 Fix Pack 39
8.0.0.12: WebSphere Application Server V8.0 Fix Pack 12
7.0.0.41: WebSphere Application Server V7.0 Fix Pack 41
8.0.0.13: WebSphere Application Server V8.0 Fix Pack 13
7.0.0.43: WebSphere Application Server V7.0 Fix Pack 43
8.0.0.14: WebSphere Application Server V8.0 Fix Pack 14
7.0.0.45: WebSphere Application Server V7.0 Fix Pack 45
8.0.0.15: WebSphere Application Server V8.0 Fix Pack 15
7.0.0.29: Java SDK 1.6 SR13 FP2 Cumulative Fix for WebSphere Application Server
7.0.0.45: Java SDK 1.6 SR16 FP60 Cumulative Fix for WebSphere Application Server
7.0.0.31: Java SDK 1.6 SR15 Cumulative Fix for WebSphere Application Server
7.0.0.35: Java SDK 1.6 SR16 FP1 Cumulative Fix for WebSphere Application Server
7.0.0.37: Java SDK 1.6 SR16 FP3 Cumulative Fix for WebSphere Application Server
7.0.0.39: Java SDK 1.6 SR16 FP7 Cumulative Fix for WebSphere Application Server
7.0.0.41: Java SDK 1.6 SR16 FP20 Cumulative Fix for WebSphere Application Server
7.0.0.43: Java SDK 1.6 SR16 FP41 Cumulative Fix for WebSphere Application Server

Subscribe

You can track all active APARs for this component.

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 V7.0.0, V8.0.0, and V8.5.0 who make  *
    *                  use of 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 Service Levels (Fix Packs) 7.0.0.29, 8.0.0.6, and
    8.5.0.2 of WebSphere Application Server versions 7.0.0,
    8.0.0, and 8.5.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 number

    PM81058

  • Reported component name

    WEBSPHERE APP S

  • Reported component ID

    5724J0800

  • Reported release

    700

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-01-21

  • Closed date

    2013-01-29

  • Last modified date

    2013-01-29

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

    PM76095

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

    PM81062

Fix information

  • Fixed component name

    WEBSPHERE APP S

  • Fixed component ID

    5724J0800

Applicable component levels

  • R700 PSY

       UP

  • R800 PSY

       UP

  • R850 PSY

       UP



Document information

More support for: WebSphere Application Server
General

Software version: 7.0

Reference #: PM81058

Modified date: 29 January 2013