Modifying method parameters?

[Maxim Moldenhauer]

Hi! I am currently using the Spring cache abstraction and am starting to look at the JSR107 annotations. We use a custom cache wrapper framework we built on top of spring to be able to have methods that take lists and methods that take single objects use the same cache.

The basic idea is if a method is invoked with a single object, we simply pass through to a normal get on the cache. If the method is invoked with a list, we iterate through all the entries and see if there is a cache hit on each entry. If all have cache hits, we return the list of cache hits. Otherwise, we pass through to the method and have to get new results even for the entries that are already cached. I'd like to have some kind of filtering concept introduced so we can actually send a subset of the keys to the method that is being invoked so we don't have to unnecessarily spend time on items that are already cached. Is there anything in JSR107 that supports this?

Thanks

Max!

[Brian Oliver]

Perhaps you can use the Cache.getAll(Set<K> keys) method?

[Maxim Moldenhauer]

The point is that some of the keys result in cache misses, but we only want to pass through the keys resulting in cache misses into the method with the caching annotation on it.

--
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/jOqh8Yx8jLc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jsr107+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Brian Oliver]

You could use Cache.containsKey(K key) to determine if the Cache has the key.

This won't cause loaders to be called either.

[Maxim Moldenhauer]

I want to plug into the annotation processing though. The goal is not to have any caching logic embedded in the business methods of the application. The steps would be.

1. The caching provider inspects the method for a caching annotation.
2. The application provides a custom plugin into the annotation processing where it checks for cache hits.
3. The custom plugin finds hits for a subset of the passed in keys
4. The custom plugin holds the cache hits in a temporary variable
5. The custom plugin removes the keys from the set that had cache hits
6. The target method is invoked with only keys that didn't have cache hits
7. The custom plugin takes the result of the method invocation and pushes it into the cache
8. The custom plugin returns the result of the method invocation plus the result of the cache hits as the return value from the method invocation.

Does that make sense? I am assuming JSR107 doesn't support this, but I thought it would be a nice feature for the future.

Thanks

Max

[Brian Oliver]

Sounds like something very specific for Spring and the type of data structure being used?

While I'm not sure I follow exactly, I generally think it's unwise for a custom-plug in to hold onto Cache hits.   Only a Cache knows what is currently "valid", especially with respect to expiry policies.   What happens if an expiry policy is configured that invalids entries after the last access?   In this case the results may be incorrect for your method?

eg: A plugin in this manner may hold onto the entries that the Cache has since expired, or worse, evicted due to memory / resource constraints.

[Maxim Moldenhauer]

Point taken, but it would only be for a short period of time while the method is being invoked. Our application is willing to accept that the entries might have been subsequently evicted after being copied out of the cache. If they are subsequently expired, the next invocation would only have to get those that were just expired. Our current implementation is very spring specific with the cache wrappers we use, but the idea is certainly generalizable.

Basically, right now, we implement our own org.springframework.cache.CacheManger instead of using the default one spring provides and getCache method can return a wrapper around the spring cache and we can do all kinds of fancy stuff by implementing the get, put, and evict with additional logic. However, it doesn't support the use case I described without modifying the List passed in and running into potential ConcurrentModificationExceptions.

Does the reference implementation already have annotation support?

Thanks. I appreciate the discussion.

Max

[Brian Oliver]

Interestingly JSR-107 Annotations are actually orthogonal to the implementations of the specification.   That is, implementations of the API don't need to provide annotation support - it's up to containers / frameworks (like Spring, Java EE etc) wanting to claim that they support JSR-107 to actually implement Annotations support.   Once this is achieve any JSR-107 compliant implementation of the specification can be used using annotations (provided by the annotation provider).

What I think you're requesting is additional annotation semantics with respect to collection types.   In that a request containing a collection type can have some parts of that request fulfilled by a backing cache, where as other parts would be satisfied by calling the underlying target method.

It's an interesting idea.  Perhaps you can raise an issue on the spec issue tracker with an example of the proposed annotation and how it fits / works with the existing annotations?   We can then consider enhancing the specification and adding to the default / example annotation provider implementations we've currently implemented.

Cheers

-- Brian

[Maxim Moldenhauer]

Sure thing. Thanks Brian!