PK98504: SQL OPTIMIZATION FOR ENTERPRISE JAVABEANS TIMERS.

Fixes are available

APAR status

Closed as program error.

Error description

An SQL call is made for each call to the javax.ejb.Timer
interface as per the Enterprise JavaBeans (EJB) Specification.
This is to ensure that the EJB Timer is using the most current
EJB Timer data which is stored in a database.  However, this
can result in a lot of SQL calls if a user iterates over, and
makes calls to, their EJB Timers.  As stated, this is a
requirement of the EJB Specification and to deviate from it
would be a violation of the EJB Specification.  However, should
a user be willing to accept an EJB Specification violation at
the benefit of a reduction in SQL statements, such a feature
should be provided.  That is, data for an EJB Timer should be
cached in the EJB Timer object itself.

Local fix

Problem summary

****************************************************************
* USERS AFFECTED:  Users of IBM? WebSphere? Application        *
*                  Server V6.1.0, V6.1.0 Feature Pack          *
*                  for Enterprise JavaBeans 3.0, and V7.0.0    *
*                  who make use of Enterprise JavaBeans Timers.*
****************************************************************
* PROBLEM DESCRIPTION: A request has been made to provide a    *
*                      mechanism to reduce the number of SQL   *
*                      calls for EJB Timer data.               *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
The javax.ejb.Timer interface has the following methods:
- TimerHandle getHandle()
- Serializable getInfo()
- Date getNextTimeout()
- Long getTimeRemaining()

The EJB Specification mandates that when any of these methods
are called, the EJB Container must make a call to the Database
which contains the timer data in order to retrieve the most
current data for the EJB Timer.  If these methods are called
often, or the user has many EJB Timers (Timers for short
hereafter) which call any one of these methods, many SQL
statements can be generated in a very short amount of time.
Even though the SQL call is a requirement of the EJB
Specification, some users may find the SQL calls too
expensive with respect to performance.  For example,
imagine the case where a timer only expires every Sunday night
at midnight.  For a whole week, calling any of the methods on
the Timer interface will return the same data and will result
in an SQL call.  Furthermore, when a Timer's 'ejbTimeout'
method is called, the data associated with the timer can not
change.  That is, the data in the Database for a Timer can
not be updated while a Timer's 'ejbTimeout' method is
running.  Therefore, the SQL generated for a call to one of
the Timer methods during a Timer's 'ejbTimeout' is a wasted
trip to the Database.

Problem conclusion

This APAR allows the user to minimize the number of SQL
statements generated for calls to the methods on the Timer
interface by caching Timer data.  When the code for this APAR
is enabled, data for the Timer will be cached in the Timer
object when the Timer object is created.  When one of the Timer
methods is called which allows for the use of cached Timer
data, the cached data will be used, thus reducing an SQL
statement.  This does however lead to the potential for a
Timer to use stale data. Cached Timer data will become stale
after the next expiration of the timer.  For example, take a
Timer which is defined to expire every hour.  When creating
the Timer object, if a user saves the resultant Timer object,
the cached data within it is current for one hour (i.e. the
cached Timer data is the same as that stored in the Database).
If the user calls any of the Timer methods within the first
hour, the Timer data is current.  It is only after an hour
passes, and hence the Timer expired, that the cached Timer
data becomes stale.  Continuing this example, if after 1.5 hrs
the user queries the EJB Container for all Timers, they would
get back a new Timer object which will contain cached data
that will be current for 30 minutes (i.e. at hour 2 the timer
will expire again, thus making my cached data stale).

It is very important to note that when enabled, this function
is not EJB Specification compliant and is a violation of the
EJB Specification.

To enable the code of this APAR, the user must set a JVM
system property; the property name is:
com.ibm.websphere.ejbcontainer.allowCachedTimerDataFor.

The syntax of the value which this property takes is in the
following form:
*[=<integer>]|<application_name>#<module_name>#<enterprisebean_n
ame>[=<integer>][:<application_name>#<module_name>#<enterprisebe
an_name>[=<integer>]]...

This syntax will now be described in detail:

The values this property takes allows a user to specify the
EJB(s) for which the property applies, as well as the
method(s) on the Timer interface for which the property
applies.  To specify which EJB(s) this property applies to,
the value used would be in the form
"<application_name>#<module_name>#<enterprisebean_name>" where:

<application_name> is the application name, as defined in the
application archive (.ear) file deployment descriptor, for the
bean which the property applies.

<module_name> is the .jar file name of the EJB module for the
bean which the property applies.

<bean_name> is the Enterprise Bean name, as defined in the EJB
module deployment descriptor, for the bean which the property
applies.

Note that more than one EJB name can be specified by
separating each EJB name with a ':'. For example:
com.ibm.websphere.ejbcontainer.allowCachedTimerDataFor=MyApp1#My
EJBModule1#MyTimerBean1:MyApp2#MyEJBModule2#MyTimerBean2.

To apply this property to all EJBs installed on the server, a
'*' can be assigned to the property.

To specify which Timer method(s) this property applies to, the
value takes an integer ("<integer>") which has been assigned
to a/an method(s) on the Timer interface.  The following Timer
methods can be configured to return cached data by using the
integer value, to the left of the Timer method, assigned to it:
1 - getHandle()
2 - getInfo()
4 - getNextTimeout()
8 - getTimeRemaining()

This allows for very fine grain control over which methods on
the Timer interface allow cached data to be used.  This
integer is assigned on a per bean basis (or all beans if '*'
is used).  The user can apply this property to any individual
methods listed above, using the assigned integer value, or
they can apply it to a combination of these methods.  For
example, to apply this property to the 'getHandle' method and
'getTimeRemaining', the user would sum the integer value for
the two methods: 9 (1+8).  To apply the property to all
four methods, the user would use the value 15 (1+2+4+8), or
the user could simply not specify an integer, that is, by
default when this property is set, it will be applied to all
methods.

Finally, to illustrate the values this property can take, some
examples will now be shown.  For the examples assume the
following:
- there are two applications, one named app1 and the other
named app2.
- each application has a module; app1 contains a module named
EJBJar1.jar and app2 contains a module named EJBJar2.jar.
- each module contains a Timer, EJBJar1.jar contains a Timer
named EJBTimer1 and EJBJar2.jar contains a Timer named
EJBTimer2.

Example 1: to apply this property to the 'getInfo' method on
EJBTimer1 and to 'getNextTimeout' and 'getTimeRemaining'  on
EJBTimer2, the following value would be used:
com.ibm.websphere.ejbcontainer.allowCachedTimerDataFor=App1#EJBJ
ar1.jar#EJBTimer1=2:App2#EJBJar2.jar#EJBTimer2=12

Example 2: to apply this property to all methods on all Timers
on all apps, the following value would be used:
com.ibm.websphere.ejbcontainer.allowCachedTimerDataFor=*=15,
or simply
com.ibm.websphere.ejbcontainer.allowCachedTimerDataFor=*

Example 3: to apply this property to 'getInfo' on all Timer on
all apps, the following value would be used:
com.ibm.websphere.ejbcontainer.allowCachedTimerDataFor=*=2

Example 4: to apply this property to 'getHandle' and
'getNextTimeout' on EJBTimer2, the following value would be
used:
com.ibm.websphere.ejbcontainer.allowCachedTimerDataFor=App2#EJBJ
ar2.jar#EJBTimer2=5


To set the property and its value use the Administrative
Console as follows:
1) Open the Administrative Console.
2) Click Servers.
3) Click Application Servers.
4) Click the server you want to configure.
5) In the Server Infrastructure area, select Java and Process
Management.
6) In the Server Infrastructure area, select Process Definition.
7) In the Additional Properties area, select Java Virtual
Machine.
8) In the Additional Properties area, select Custom Properties.
9) Select the New box.
10) In the Name entry field, type
com.ibm.websphere.ejbcontainer.allowCachedTimerDataFor
11) In the Value entry field, type the value
12) Select OK and save the changes.
13) Restart the Application Server.


The fix for this APAR is currently targeted for
inclusion in Service Levels (Fix Packs) 6.1.0.29,
Enterprise JavaBeans 3.0 Feature Pack Fix Pack 29
(6.1.0.29), and 7.0.0.9 of WebSphere Application Server
versions 6.1.0, and 7.0.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
PK98504
Reported component name
WEBSPHERE APP S
Reported component ID
5724J0800
Reported release
61W
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2009-10-13
Closed date
2009-10-20
Last modified date
2009-10-20

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
WEBSPHERE APP S
Fixed component ID
5724J0800

Applicable component levels

R61A PSY
UP
R61H PSY
UP
R61I PSY
UP
R61P PSY
UP
R61S PSY
UP
R61W PSY
UP
R61Z PSY
UP
R700 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":"6.1","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
29 December 2021

Tips

PK98504: SQL OPTIMIZATION FOR ENTERPRISE JAVABEANS TIMERS.

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

R61A PSY

R61H PSY

R61I PSY

R61P PSY

R61S PSY

R61W PSY

R61Z PSY

R700 PSY

Document Information

Share your feedback

Need support?