PK84675: OPTIMISTICUPDATEFAILUREEXCEPTION occurring even though an update did not occur

Fixes are available

APAR status

Closed as program error.

Error description

An OptimisticUpdateFailureException is occuring when
attempting to store a CMP 1.x Entity EJB even though the
bean has not been updated.  This issue occurs on
WebSphere Application Server version 6.0.2 up to and including
version 7.0.0.

Local fix

Problem summary

****************************************************************
* USERS AFFECTED:  All users of IBM WebSphere Application      *
*                  Server V6.0.2, V6.1.0, V6.1.0 Feature Pack  *
*                  for Enterprise JavaBeans 3.0, and V7.0.0    *
*                  who make use of CMP 1.x bean with           *
*                  optimistic concurrency.                     *
****************************************************************
* PROBLEM DESCRIPTION: Extraneous store of a CMP 1.x Entity    *
*                      Bean causes an                          *
*                      OptimisticUpdateFailureException.       *
*                                                              *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
The scenario causing the exception is as follows:
1) In a transaction a CMP 1.x entity bean is retrieved from the
data base and updated (i.e. 'dirtied').  The access and update
of the bean is perfomed with an optimistic concurrency control.
Internal to WebSphere Application Server EJB Container code is
state which indicates that the bean has been 'dirtied'.
2) When the transaction ends, the 'dirty' bean is written back
to the data base and the bean is pooled.  When the bean is
pooled, the state used to indicate that the bean is dirty is
not re-set to its default state.
3) When another request in another transaction is made for the
bean, the bean is taken out of the pool to service the
request.  Given that the bean was put into the pool with state
indicating it is 'dirty' as described in #2, the bean will be
written to the data base at the end of the transaction even if
the bean was accessed in a read only manner(i.e. should not be
'dirty').

For the stated scenario, at best the bean is unnecessarily
(extraneously) written to the data base when it is incorrectly
marked as 'dirty'.  Of course any extra trips to the data
base is never desirable.  At worst the
OptimisticUpdateFailureException may result.  To describe
when this exception may result we must take the scenario
described above one step further, as follows: when two
transactions are operating on the same data base row (and as
such the same bean) at the same time, at transaction commit
both beans will be stored given the state indicating it is
'dirty'.  Since both transaction are writing to the same
row at roughly the same time, and given that an optimistic
concurrency control is being used, only one transaction can
successfully perform the store and the other must fail with an
OptimisticUpdateFailureException.  That is, when the second
transaction attempts to perform the store, it will be detected
that another transaction has written to the row sometime after
the second transaction read the row.
This issue only occures for CMP 1.x Entity Beans where an
optimistic concurrency control is used.

Problem conclusion

With this fix, code has been added to ensure that state
indicating a bean is 'dirty' is cleared before the bean is
pooled.

The fix for this APAR is currently targeted for inclusion in
Service Levels (Fix Packs) 6.0.2.37, 6.1.0.27, Enterprise
JavaBeans 3.0 Feature Pack Fix Pack 27 (6.1.0.27), and 7.0.0.5
of WebSphere Application Server versions 6.0.2, 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
PK84675
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-04-14
Closed date
2009-05-21
Last modified date
2009-05-21

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

R60A PSY
UP
R60H PSY
UP
R60I PSY
UP
R60P PSY
UP
R60S PSY
UP
R60W PSY
UP
R60Z PSY
UP
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

PK84675: OPTIMISTICUPDATEFAILUREEXCEPTION occurring even though an update did not occur

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

R60A PSY

R60H PSY

R60I PSY

R60P PSY

R60S PSY

R60W PSY

R60Z PSY

R61A PSY

R61H PSY

R61I PSY

R61P PSY

R61S PSY

R61W PSY

R61Z PSY

R700 PSY

Document Information

Share your feedback

Need support?