Craig
On May 19, 2008, at 6:31 PM, Patrick Linskey wrote:
I haven't read through all the cases below, but in general, I believe that we should strive to keep the behavior identical, and that discrepancies should be considered bugs unless there is some overriding reason to keep the different behavior.-Patrick On May 19, 2008, at 12:41 PM, David Wisneski wrote:I'd be interested in folks opinion on the following.Currently in section 10.1 of the OpenJPA doc on DataCache is the statement"OpenJPA's data cache is designed to provide significant performance increases over cacheless operation, while guaranteeing thatbehavior will be identical in both cache-enabled and cacheless operation."In various tests we have found this statement is not quite correct onvarious corner cases. And I would propose the following clarification"Behavior will be the same in both cache-enables and cachless operations except for the following cases: " 1. If inverse relationships are not set or set to inconsistent values, the inconsistent values will be stored in the DataCache and restored upon entity reactivation. Using the property openjpa.InverseManager=true can eliminate this type of problem. This differs from the situation where there is no DataCache, the inverse relationships are not stored in the database but are rather rebuild upon request. 2. Using a @PrimaryKeyJoinColumn on a unidirectional one-to-one relationship and not setting the relationship value to be consistent with the primary key value. The inconsistent values will be stored in the DataCache and restored upon entity activity. 3. Updating a field annotated with insertable=false and/or updateable=false. Updates to these fields will be stored in the DataCache and restored upon entity reactivation. This differs from the situation where there is no DataCache, the field values are not stored and upon reactivation the values are reset. 4. Mapping two or more fields to the same table column and setting the fields to different values. The DataCache treats the fields as independent values and the two values will be stored and laterrestored. This differs from the situation where there is no DataCacheonly one value is stored and upon reactivation both values will be consistent. 5. Changing a field from lazy to eager in a fetch plan will not have any affect if the DataCache is used to retrieve data upon entity reactivation and the field's state in the DataCache entry was not retrieved. 6. The EntityManager method refresh will not retrieve the current committed data from the database, rather it will retrieve the current data from the DataCache. If applications have updated the database bypassing the DataCache (which could happen using a nativeQuery update, a JPA QL bulk update or a legacy application update) a refresh will not cause the changed data in the database to be loaded. David Wisneski-- Patrick Linskey 202 669 5907
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
