APAR status
Closed as program error.
Error description
When a CMP 1.1 bean instance is loaded for read only use with
a custom finder, a warning should be generated if the EJB
Container must refresh/persist the bean instance data to the
database because it was changed. The warning is only written
out once per bean instance type per server start.
In this case, if a bean instance was dirtied after being loaded
in an lazy enumeration scenario and was the 26th instance or
greater returned in the query, the warning message would not
be issued.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Base Product 5.0, *
* 5.0.1 and 5.02 customers using EJB CMP 1.1 *
* custom finder queries returning greater *
* than 25 entries. *
****************************************************************
* PROBLEM DESCRIPTION: If a CMP 1.1 home custom finder has *
* an access intent of update and returns *
* more than 25 items, each particular *
* bean instance returned will be loaded *
* with read only status attribute that *
* is tracked by the container. *
* Once the bean instance of a certain *
* type is updated, an incorrect error *
* message will be generated indicating *
* the bean was updated but loaded in a *
* read only scenario for that bean type. *
* All bean instances will still be *
* stored correctly so data integrity is *
* not an issue here, and the only *
* incorrect behavior is that a single *
* error message will be generated *
* incorrectly for each bean type this *
* scenario applies to. *
****************************************************************
* RECOMMENDATION: There is not a workaround for this behavior *
* other than installing the EJBContainer *
* Cumulative efix 10-13 or later for WebSphere *
* 5.0 and 5.01, or applying the cumulative *
* fix containing this apar for 5.02. *
****************************************************************
WebSphere Application Server users that have
implemented a CMP 1.1 home custom finder method
with update intent that returns greater than 25
instances will incorrectly generate a single
error message for each bean type this scenario
applies to. There is not a data integrity issue,
even the beans have a read-only status, if the
state is changed it will be persisted to the database.
Problem conclusion
A change was made to ensure that bean instances
loaded after the first 25 in this scenario have
the correct "update" status, and this precludes
the error reporting for that bean type if one
instance is updated and persisted.
Temporary fix Comments
APAR information |
APAR number |
PQ79250 |
Reported component name |
WAS BASE 5.0 |
Reported component ID |
5630A3600 |
Reported release |
00W |
Status |
CLOSED PER |
PE |
NoPE |
HIPER |
NoHIPER |
Special Attention |
NoSpecatt |
Submitted date |
2003-10-06 |
Closed date |
2003-10-24 |
Last modified date |
2003-10-24 |
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Modules/Macros
Publications Referenced
Applicable component levels |
R00W PSY |
UP |
|