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: StoreCache/DataCache is not null even when DataCache is configured to be inactive
Date Thu, 22 May 2008 20:21:20 GMT

On May 22, 2008, at 7:36 AM, Patrick Linskey wrote:

>>> There should not be any reason for the application to know whether  
>>> a  data
>>> cache has been set up or not.
>>
>> StoreCache is a published/exposed API with methods that allow user to
>> operate on L2 cache. Hence a user may find it counter-intuitive  
>> when s/he
>> explicitly configures openjpa.DataCache=false but still gets a no-op
>> StoreCache.
>
> The StoreCache is explicitly designed to never be null; people  
> should not rely on its nullness to determine whether or not a cache  
> is present.
>
>> This no-op StoreCache also causes the implementation  
>> (StoreCacheImpl) to
>> check whether it has non-null real delegate or not for every method.
>
> If that is a demonstrable performance issue, then we should create a  
> NoOpStoreCacheImpl that is put in place when the data caches are all  
> off.

I can't imagine that there's any performance impact of testing for a  
null value. The primary motivation is usability.
>
>
>>> So if the openjpa.DataCache is set to "false", a data cache that   
>>> doesn't
>>> do anything is instantiated.
>>
>> The other choice would have been not to instantiate anything at all  
>> and
>> return null. I am trying to find out what is the rationale of a no-op
>> implementation versus a pure null.
>> Is it to save the user from NPE or something else internal to  
>> OpenJPA?
>
> Yes; the idea is that most code should not need to care about  
> whether or not caching is turned on. For example, if I want to  
> ensure that all the Person records are cleared from the cache, it  
> doesn't really matter if the cache is on or not.

Exactly.

> So, instead of making the developer check the status (and, more  
> importantly, to protect against the case where the developer does  
> not, and doesn't test with no caching), we simply return a no-op  
> data structure.

By the way, this feature was originally developed and specified in the  
JDO API, and the OpenJPA implementation is faithful to the pattern in  
the specification.

Craig
>
>
> -Patrick
>
> On May 22, 2008, at 5:23 AM, Pinaki Poddar wrote:
>
>>
>> Hi Craig,
>>> There should not be any reason for the application to know whether  
>>> a  data
>>> cache has been set up or not.
>>
>> StoreCache is a published/exposed API with methods that allow user to
>> operate on L2 cache. Hence a user may find it counter-intuitive  
>> when s/he
>> explicitly configures openjpa.DataCache=false but still gets a no-op
>> StoreCache.
>>
>> This no-op StoreCache also causes the implementation  
>> (StoreCacheImpl) to
>> check whether it has non-null real delegate or not for every method.
>>
>>> So if the openjpa.DataCache is set to "false", a data cache that   
>>> doesn't
>>> do anything is instantiated.
>>
>> The other choice would have been not to instantiate anything at all  
>> and
>> return null. I am trying to find out what is the rationale of a no-op
>> implementation versus a pure null.
>> Is it to save the user from NPE or something else internal to  
>> OpenJPA?
>>
>>
>>
>>
>> -- 
>> View this message in context: http://www.nabble.com/StoreCache-DataCache-is-not-null-even-when-DataCache-is-configured-to-be-inactive-tp17380291p17403110.html
>> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>>
>
> -- 
> 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