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 Wed, 28 May 2008 01:11:19 GMT
> b) bypasses Data cache for refresh() altogether

Historically, we've assumed that for the purposes of refresh(), the  
data cache is always correct with respect to the database. I.e., the  
assumption has been that if changes were made out-of-band, then the  
developer would call DataCache.evict() prior to refresh(). It would  
seem that your suggestion significantly changes this assumption.

For the case of Broker.evict() calls, the Broker has a special setting  
(setEvictFromDataCache()) that allows configuration of whether or not  
Broker.evict() also calls DataCache.evict(). We should consider this  
precedent and the prior assumptions when coming up with a strategy for  
changing the semantics of refresh().

> c) throws away 'optimization' for a single entity

Can you describe this in more detail? Optimizations are generally  
there for a reason -- getting rid of it might very well lead to sub- 
optimal behavior.

-Patrick

On May 28, 2008, at 9:38 AM, Pinaki Poddar wrote:

>
> Hi Craig,
>  Committed revision 660753 towards a model that
> a) corrects refresh() behavior of single, clean entity
> b) bypasses Data cache for refresh() altogether
> c) throws away 'optimization' for a single entity
>
> Pinaki
>
>
> Craig L Russell wrote:
>>
>> Hi Pinaki,
>>
>> On May 27, 2008, at 3:00 PM, Pinaki Poddar wrote:
>>
>>>
>>> After some more analysis of refresh() issue...
>>>
>>> 1. it is observed that a refresh of a single, clean instance never
>>> hits the
>>> database -- irrespective of whether Data Cache is active or not.
>>> That does
>>> not appear spec compliant.
>>
>> I agree.
>>>
>>>
>>> 2. refresh() behaves differently on current lock level. With NO LOCK
>>> it
>>> reads from Data Cache; on any stronger lock it hits the database.
>>> I am of the opinion that all refresh() must bypass data cache
>>> altogether
>>> always -- because refresh() seems to express explicit intent of the
>>> user to
>>> read data from database (say when the application thinks that out- 
>>> of-
>>> band
>>> modifications may have taken place on the database).
>>
>> I agree.
>>>
>>>
>>> 3. There is an 'optimization' on BrokerImpl.refresh() -- one for a
>>> single
>>> entity and other for a collection. Removing that optimization (which
>>> leaves
>>> some maintenance concern of similar but not same code blocks) is
>>> another
>>> suggestion.
>>
>> Seems that if the user calls refresh on a single entity or on a
>> collection, then we should hit the database every time. Who are we to
>> know that the database hasn't changed in the last millisecond? Sure,
>> we're smart, but we're not omniscient.
>>
>> Craig
>>>
>>>
>>>
>>> Comments?
>>>
>>>
>>> -- 
>>> View this message in context:
>>> http://www.nabble.com/datacache-tp17326391p17501042.html
>>> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>>>
>>
>> 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!
>>
>>
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/datacache-tp17326391p17502434.html
> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>

-- 
Patrick Linskey
202 669 5907


Mime
View raw message