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

Fixes are available

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

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
29 October 2021

Tips

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

Fixes are available

Subscribe

APAR status

Closed as program error.

Error description

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

APAR number

Reported component name

Reported component ID

Reported release

Status

PE

HIPER

Special Attention

Submitted date

Closed date

Last modified date

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

Fixed component ID

Applicable component levels

R700 PSY

R800 PSY

R850 PSY

Document Information

Share your feedback

Need support?