openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Linskey <plins...@gmail.com>
Subject Re: datacache
Date Tue, 20 May 2008 01:31:52 GMT
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


Mime
View raw message