PK37379: CMP ENTITY BEANS USING CMR WITH ENABLED DATACACHE SHOW INCONSISTENT RESULTS DURING READ. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description When 2 CMP beans bound by a CMR have different cache lifetimes, any deletion of an instance of the related CMP in the cache, will cause other instances bound by the same value of the relationship to disappear in the same transaction. Here is an example of the behavior that is seen 2 CMPs have a 1:n relationship, which is imlemented through CMR. Say we have a company <-> employee relationship. Both, company and employee beans use the EJB datacache (ELAPSED_TIME invalidations). The company bean is fetched through its primary key and then the collection of employees is iterated through. While this works fine for a couple of calls, after a while the size and the content of the employee collection starts to vary even there are no changes applied on the underlying database. [12/1/06 10:52:59:133 CET] 2e607801 SystemOut O comp1 employes emp1, emp3, emp2, <<----- ok, company has 3 employees [12/1/06 10:53:10:930 CET] 2e607801 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:18:305 CET] 348fb802 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:19:618 CET] 348fb802 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:20:618 CET] 348fb802 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:21:602 CET] 348fb802 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:22:415 CET] 348fb802 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:23:243 CET] 348fb802 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:24:149 CET] 348fb802 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:24:837 CET] 348fb802 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:26:181 CET] 348fb802 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:27:712 CET] 348fb802 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:39:853 CET] 2e607801 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:44:822 CET] 2e607801 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:49:244 CET] 2e607801 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:53:54:056 CET] 2e607801 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:54:09:994 CET] 348fb802 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:54:37:682 CET] 2e607801 SystemOut O comp1 employes emp1, emp3, emp2, [12/1/06 10:54:39:214 CET] 2e607801 SystemOut O comp1 employes emp3, <<----------------- here starts the problem [12/1/06 10:54:40:932 CET] 2e607801 SystemOut O comp1 employes emp3, [12/1/06 10:54:42:167 CET] 2e607801 SystemOut O comp1 employes emp3,Local fix N/AProblem summary **************************************************************** * USERS AFFECTED: User of persistence manager with cache * * lifetimes enabled in WebSphere Application * * Server version 5.1.1. * **************************************************************** * PROBLEM DESCRIPTION: When two bean instances are bounded * * by a CMR relationship, a cache lifetime * * expired instance results in the other * * instance being removed from the cache. * **************************************************************** * RECOMMENDATION: * **************************************************************** This problem occurs in situations involving two CMP entity beans with different cache lifetimes specified. The two beans also need to be bounded by a CMR relationship. If one of the instances of such a bean is deleted and therefore removed from the cache, then erroneously all the corresponding bean instances bound by the same value of the foreign key are removed from the cache. As a result, other bean instances related by the same foreign key value are no longer accessible in the same transaction.Problem conclusion Code change makes sure that the cache stays synchronized. Only the cache lifetime expired instance will be removed from the cache and any bean instances related by the same foreign key will remain in the cache. The fix for this APAR is currently targeted for inclusion in cumulative fix 5.1.1.14. Please refer to the recommended updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 10S
Software edition:
Reference #: PK37379
IBM Group: Software Group
Modified date: Feb 21, 2007
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.