Exception cache vs. regular cache

[Stéphane Nicoll]

Hi,

I am adding the support of JSR-107 cache annotations in the Spring framework.

It's unclear to me if the cache resolution has différent meaning for the regular cache and the exception cache. In the RI, the exception cache can be "null" while the regular cache is assumed to be set. 

Said differently, if you specify an "exceptionCacheName", the relevant CacheResolver gets  called and if it returns "null", no exception caching occurs. I don't see this written down in the spec. According to the spec, the presence of "exceptionCacheName" triggers the handling of exception.

What's the intend here? 

Thanks!

S.

[Stéphane Nicoll]

Anyone?

[Chris Dennis]

This isn’t my really my area – but I’m going to chime in to at least give you one opinion.  I would expect resolution to work in an identical manner for both the regular cache and the exception cache.  On my reading of the spec I don’t see anything that specifies how a cache implementation is supposed to behave if the CacheResolver returns null for either the regular or exception caches (or any language that disallows returning null).  I would interpret that as meaning the implementor is free to choose what to do… the logical choices being either an NPE or no caching.

Maybe Rick Hightower or Eric Dalquist have some further input on this, since they were much more involved in the annotations side of the spec.

Chris

--
You received this message because you are subscribed to the Google Groups "jsr107" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr107+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jens Wilke]

On Tuesday 15 April 2014 11:13:27 Chris Dennis wrote:
> This isn’t my really my area – but I’m going to chime in to at least give
> you one opinion. I would expect resolution to work in an identical manner
> for both the regular cache and the exception cache. On my reading of the
> spec I don’t see anything that specifies how a cache implementation is
> supposed to behave if the CacheResolver returns null for either the regular
> or exception caches (or any language that disallows returning null). I
> would interpret that as meaning the implementor is free to choose what to
> do… the logical choices being either an NPE or no caching.
>
> Maybe Rick Hightower or Eric Dalquist have some further input on this, since
> they were much more involved in the annotations side of the spec.
>
> Chris

Hi Stéphane, Hi Chris,

my 2 cents on this:

You describe an erroneous situation. I would say a robust implementation should
issue warnings and/or refuse operation at all.

From the spec point of view I would strongly opt for the implication that "nothing is allowed
to return null otherwise specified". That means, it is the CacheResolvers business to handle
the situation. E.g. by a warning and returning a (configuarable?) default cache or
by throwing an exception.

If the programmer specifies a cache by an annotation, it may have a serious impact if
no caching is done at all, e.g. by a configuration mistake.

For early implementations I would strongly recommend the most easiest option, that
is, throwing an exception and let the user/admin solve the problem.

Disclaimer: I am not really an annotations geek.....

Hope that helps.

Best,

Jens

--
"Everything superfluous is wrong!"

// Jens Wilke - headissue GmbH - Germany
\// http://www.headissue.com

[Stephane Nicoll]

Unfortunately, it's not that easy. 

The Javadoc of "exceptionCacheName" states "If not specified no exception caching is done."[1]. This may sounds like a safe check: if exceptionCacheName on the annotation isn't set, then we simply don't call the CacheResolver. The problem is that you may specify a custom cache resolver (through the cache resolver factory) and that custom cache resolver may not care at all about the fact that the exceptionCacheName has a value or not (because its own logic doesn't require it).

Right now, what the Spring framework support does is checking if the exceptionCacheName attribute is set. If it's not set, no exception cache resolver is associated with the operation[2] (down the road, if the resolver is not set, exception cache is disabled). Note that if exceptionCacheName is set and a *custom* resolver returns null, then exception caching is disabled as well which I personally think it's a good thing as it allows for more flexibility than the exception type filter at the annotation level.

What I'd like to see is a less strict javadoc. To me, stating that "If not specified no exception caching is done" beats the purpose of having custom cache resolvers in the first place. Those can fully ignore the value of the annotation and resolve the exception cache name based on the method signature and/or runtime arguments. The problem with this is that you end up with a weird contract for CacheResolver as returning null for regular caches does not sound like it was the plan.

I understand that there is no perfect answer to this problem but the current Javadoc does not feel right. 

Thoughts?

Cheers,

S.

[1] https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/annotation/CacheResult.java#L150

[2] https://github.com/spring-projects/spring-framework/blob/master/spring-context-support/src/main/java/org/springframework/cache/jcache/interceptor/AnnotationCacheOperationSource.java#L127

--
You received this message because you are subscribed to a topic in the Google Groups "jsr107" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jsr107/vsQMJqFtMgg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jsr107+un...@googlegroups.com.

[Jens Wilke]

On Thursday 17 April 2014 10:47:32 Stephane Nicoll wrote:
> Unfortunately, it's not that easy.
>
> The Javadoc of "exceptionCacheName" states "If not specified no exception
> caching is done."[1]. This may sounds like a safe check: if
> exceptionCacheName on the annotation isn't set, then we simply don't call
> the CacheResolver. The problem is that you may specify a custom cache
> resolver (through the cache resolver factory) and that custom cache
> resolver may not care at all about the fact that the exceptionCacheName has
> a value or not (because its own logic doesn't require it).
>
> Right now, what the Spring framework support does is checking if the
> exceptionCacheName attribute is set. If it's not set, no exception cache
> resolver is associated with the operation[2] (down the road, if the
> resolver is not set, exception cache is disabled). Note that if
> exceptionCacheName is set and a *custom* resolver returns null, then
> exception caching is disabled as well which I personally think it's a good
> thing as it allows for more flexibility than the exception type filter at
> the annotation level.

So the question is:

Who should fulfill the annotations' contract, the CacheResolver or the "glue"
that calls it? Right?

> What I'd like to see is a less strict javadoc. To me, stating that "If not
> specified no exception caching is done" beats the purpose of having custom
> cache resolvers in the first place.

> Those can fully ignore the value of the
> annotation and resolve the exception cache name based on the method
> signature and/or runtime arguments.

Got your point!

It is also not consistent in itself, since cacheName is optional and has a reasonable
default. Its obvious that a developer wants to specify that exception caching
needs to be done, but does not want to specify a name for it, since it is
not needed at other places. So that's a bug.

> The problem with this is that you end
> up with a weird contract for CacheResolver as returning null for regular
> caches does not sound like it was the plan.

Some further weird thoughts on this:

If no caching is requested, you can return a Cache implementation that
is not caching at all. Where is written that "not caching" does mean there is
no cache instance? That's missing on the CacheResolver JavaDoc.....

> I understand that there is no perfect answer to this problem but the
> current Javadoc does not feel right.

+1

> Thoughts?

A possible answer is in the RI.

- A null cache means no caching
- the CacheResolver decides and only the CacheResolver

See getExceptionCache() here:
https://github.com/jsr107/RI/blob/master/cache-annotations-ri/cache-annotations-ri-common/src/main/java/org/jsr107/ri/annotations/AbstractCacheResultInterceptor.java

Still, there is something missing. How can a developer, say that we need exceptionCaching
without specifying a name? Since the name may be meaningless, I would opt for a convention,
for the case, it is indeed meaningless, e.g. exceptionCache="default" or exceptionCache="".

The JavaDoc needs to be clarified:
- CacheResolver: returns a Cache or null if no caching should occur
- At the annotation exceptionCache: Specifying this annotation means caching for exceptions
is requested. When a custom CacheResolver is in place the behaviour is determined by the
CacheResolver.

Sorry for my previous post on this, I was digging in the fog....

Cheers,