Mixing JCache annotations with imperative code

[Jaromir Hamala]

Hi,

I wonder whether the spec should address (or even encourage?) mixing declarative & imperative access to caches.

Currently the spec. defines caching annotations. As a user I can supply my own (cache) key generator strategy, but a generated key has to implemented GeneratedCacheKey

-> 

if I want to access to same cache imperatively then I have to either wrap my business keys inside objects implementing the GeneratedCacheKey or pollute business objects with JCache specific code.

I tried use the MicroProfile Demo application as a guinea pig:

The application (imperatively) stores data into JCache and uses `Long` as a cache key. I wanted to use the @CacheRemove annotation to invalidate entries from this cache.

It is possible but it does not feel very good:

1. The spec does not define a default implementation CacheKeyGenerator. It's up to a container to provide one -> When I want to access the same cache imperatively then I always have to implement a custom strategy (or rely on a container-specific implementation)

2. Custom strategies are somewhat awkward to implement.  There is so much boilerplate when all I want to do is to use a specific method argument to calculate a cache key. The CacheKeyGenerator code feels too low-level for what it does. Spring uses its Expression Language to select keys - that makes it much easier to use.

3. It requires the CacheKeyGenerator to wrap everything in a class implementing the GeneratedCacheKey  interface. This is the result. It does not feel very good either.

Now this exercise leads to these questions:

1. Why the CacheKeyGenerator has to return GeneratedCacheKey? Would be object enough? If the Cache interface does not force all keys to implement a specific interface why the CacheKeyGenerator should? Is it possible to relax the CacheKeyGenerator contract?

2. Should the spec allow user code to create an instance of the GeneratedCacheKey impl supplied by the container? See https://github.com/Adopt-a-JSR/jcache-javaee/issues/4

3. This is probably the most important question: Does the EG want to encourage mixing imperative and declarative approach at all? 

Cheers,

Jaromir

[Enrico Olivelli]

Hi Jaromir,
You may take a look at https://github.com/Adopt-a-JSR/jcache-javaee/issues/4

There are a lot of discussions open about JCache and JavaEE integration

Cheers
Enrico

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

--

-- Enrico Olivelli

[Jaromir Hamala]

Hi Enrico,

thanks for the pointer. I commented on the issue. 

Cheers,

Jaromir

[Greg Luck]

Jaromir

1. Don't know. I asked Eric but he is not responsive. I wonder if Object is enough. I don't want to mess with the code in 1.1 but in 2.0 we should.

3. Yes. We should. They are supposed to be two different ways to interact with the same caches. 

[ckn...@ohdsi.org]

Hi, I've run into this exact issue, and I can say that Object is absolutely enough, we shouldn't need to implement an interface to access a cache by key. The same principle is in the HashMap.get() implementation: even tho you could declare a HashMap<K,V>, the get method signature takes an Object because you'll be able to lookup a value in the map by any object who's hash() and equals() matches the element in the map.  The Cache should work the same way. But because of the API definition, you have all the problems that Jaromir mentioned....tons of boilerplate code to create a generated key from the different sources of keys when they all will have the same implementation (such as represented by a Long).

If this can be changed in 2.0, that'd be awesome.