You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Pinaki Poddar <pp...@apache.org> on 2008/05/22 00:08:51 UTC
StoreCache/DataCache is not null even when DataCache is configured
to be inactive
The following configuration
<property name="openjpa.DataCache" value="false"/>
is expected to configure the environment without a DataCache/StoreCache. Is
that right expectation?
However, OpenJPAEntityManagerFactory configured as above fails following
assertions:
1: assertNull(emf.getStoreCache());
2: assertNull(emf.getConfiguration().getDataCacheManagerInstance());
but succeeds the following:
3: assertNull(((StoreCacheImpl)emf.getStoreCache()).getDelegate());
4.
assertNull(emf.getConfiguration().getDataCacheManagerInstance().getSystemDataCache());
Anyone to shed light why StoreCache or DataCacheManager is instantiated even
when DataCache is set to be false?
--
View this message in context: http://www.nabble.com/StoreCache-DataCache-is-not-null-even-when-DataCache-is-configured-to-be-inactive-tp17380291p17380291.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Re: StoreCache/DataCache is not null even when DataCache is
configured to be inactive
Posted by Pinaki Poddar <pp...@apache.org>.
Hi,
Thanks for the clarifications. I get it now.
Pinaki
--
View this message in context: http://www.nabble.com/StoreCache-DataCache-is-not-null-even-when-DataCache-is-configured-to-be-inactive-tp17380291p17413977.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Re: StoreCache/DataCache is not null even when DataCache is configured
to be inactive
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
Re: StoreCache/DataCache is not null even when DataCache is configured to be inactive
Posted by Patrick Linskey <pl...@gmail.com>.
>> 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.
>> 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. 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.
-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
Re: StoreCache/DataCache is not null even when DataCache is
configured to be inactive
Posted by Pinaki Poddar <pp...@apache.org>.
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.
Re: StoreCache/DataCache is not null even when DataCache is configured
to be inactive
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Pinaki,
On May 21, 2008, at 3:08 PM, Pinaki Poddar wrote:
>
> The following configuration
>
> <property name="openjpa.DataCache" value="false"/>
>
> is expected to configure the environment without a DataCache/
> StoreCache. Is
> that right expectation?
>
> However, OpenJPAEntityManagerFactory configured as above fails
> following
> assertions:
>
> 1: assertNull(emf.getStoreCache());
> 2: assertNull(emf.getConfiguration().getDataCacheManagerInstance());
>
> but succeeds the following:
>
> 3: assertNull(((StoreCacheImpl)emf.getStoreCache()).getDelegate());
> 4.
> assertNull
> (emf
> .getConfiguration
> ().getDataCacheManagerInstance().getSystemDataCache());
>
>
> Anyone to shed light why StoreCache or DataCacheManager is
> instantiated even
> when DataCache is set to be false?
The reason for instantiating DataCacheManager is so applications don't
have to explicitly test for it in order to use it.
There should not be any reason for the application to know whether a
data cache has been set up or not. There is no user-visible behavior
(see other thread) based on whether there is a data cache or not.
So if the openjpa.DataCache is set to "false", a data cache that
doesn't do anything is instantiated.
Craig
>
>
> --
> View this message in context: http://www.nabble.com/StoreCache-DataCache-is-not-null-even-when-DataCache-is-configured-to-be-inactive-tp17380291p17380291.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!