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
