Re: StoreCache/DataCache is not null even when DataCache is configured to be inactive

[Craig L Russell]

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

explicitly configures openjpa.DataCache=false but still gets a no-op
StoreCache.

operate on L2 cache. Hence a user may find it counter-intuitive when s/he

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.

return null. I am trying to find out what is the rationale of a no-op
implementation versus a pure null.

The other choice would have been not to instantiate anything at all and 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.

Craig

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.

-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

explicitly configures openjpa.DataCache=false but still gets a no-op
StoreCache.


check whether it has non-null real delegate or not for every method.

operate on L2 cache. Hence a user may find it counter-intuitive when s/he This no-op StoreCache also causes the implementation (StoreCacheImpl) to

So if the openjpa.DataCache is set to "false", a data cache that doesn't

do anything is instantiated.

return null. I am trying to find out what is the rationale of a no-op
implementation versus a pure null.





--
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.

The other choice would have been not to instantiate anything at all and Is it to save the user from NPE or something else internal to OpenJPA?

--
Patrick Linskey
202 669 5907

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature