openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: datacache
Date Tue, 20 May 2008 02:22:02 GMT
I agree with Patrick. I think the main reason behavior differs is  
simply lack of test cases.

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 that
>> behavior will be identical in both cache-enabled and cacheless  
>> operation."
>>
>> In various tests we have found this statement is not quite correct on
>> various 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 later
>> restored.  This differs from the situation where there is no  
>> DataCache
>> only 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message