通过注释从对象类型创建缓存(Create cache from object type through annotations)

通过注释从对象类型创建缓存(Create cache from object type through annotations)

所以，

我正在尝试将现有的缓存（ehcache）转换为点亮缓存，并迁移到spring注释。 我遇到了一些困难，使得注释与我们现有的缓存一样工作 - 我们现有的缓存是在我们缓存新类的某些东西时自动创建的，并且新缓存与对象的类具有相同的名称。

所有当前缓存逻辑（以及大多数普通CRUD操作逻辑）都在一个抽象类中，该类扩展了所有持久对象。 然而，在研究spring注释时，似乎我需要在方法上定义缓存名称 - 这显然不适用于抽象类，除非我希望所有对象都在同一个缓存中（可能但绝对不是理想）。 理想情况下，我将缓存名称指定为“＃this.class.toString”，但缓存名称中不允许使用SPEL，就像它在密钥中一样。

似乎动态解决缓存的唯一方法是创建自己的缓存解析器，但由于某种原因，IgniteCache不会扩展springframework Cache，而是javax Cache，缓存解析器必须返回前者。 所以我甚至都不清楚Ignite缓存如何与spring注释一起工作？

这对我来说似乎是一个非常简单的用例，所以看起来很奇怪Spring注释迫使我在方法上提供一个显式名称，当我假设大多数任何有效大小的应用程序都抽象出它们的持久性方法时，我觉得我一定错过了一些关键文档，但我肯定找不到它。 有没有办法在具体实现上指定缓存的名称，但是在抽象方法上保留缓存注释？

谢谢！

So,

I'm trying to convert our existing caching (ehcache) to ignite cache, and migrating to spring annotations. I'm running into some difficulty making the annotations work the same as our existing caches though - our existing caches are created automagically whenever we cache something of a new class, and the new cache has the same name as the object's class.

All the current cache logic (along with most of the normal CRUD operation logic) is in an abstract class that's extended for all our persistent objects. In researching the spring annotations, though, it seems like I need to define the cache name on the method - which obviously doesn't work for the abstract class, unless I want all our objects to be in the same cache (possible but definitely not ideal). Ideally I'd specify the cache name as "#this.class.toString", but SPEL isn't allowed in the cache name, like it is in the key.

It seems like the only way to resolve the cache dynamically is by creating your own cache resolver, but for some reason IgniteCache doesn't extend springframework Cache, but javax Cache, and the cache resolver has to return the former. So I'm not even clear how Ignite cache works with spring annotations at all?

This seems like a pretty straightforward use case to me, so it seems weird that spring annotations force me to provide an explicit name on the method, when I'd assume most applications of any significant size are abstracting their persistence methods, and I feel like I must have missed some crucial documentation, but I sure can't find it. Is there a way to specify the name of the cache on the concrete implementation, but keep the caching annotation on the abstract methods?

Thanks!

最满意答案

你的问题非常密集，你要做的事情并不是很清楚。 什么是“你现有的缓存”一开始？ 您需要一些方法来标记您实际缓存内容的位置。 我假设你已经明白你需要在那里放一个缓存注释。

至于自动创建缓存，我不会切换到不同的缓存系统并尝试实现它。 尝试首先使用现有缓存基础结构迁移到缓存注释，然后迁移到点火。

让我们假装你们两个都做。 你是对的CacheResolver是要走的路，它可以适应常规的org.springframework.cache.Cache或javax.cache.Cache 。 一旦你有一个有效的设置，我会做以下事情：

在CacheResolver实现中，注入已配置的缓存管理器 根据方法调用，找出要使用的缓存名称（获取方法的返回类型，提取FQN） 检查缓存管理器是否具有此类缓存。 如果是，请返回。 如果它没有创建新缓存并添加它然后返回它

如果您正在使用JCacheCacheManager ，则可以调用addCache来创建新缓存，然后将结果包装在JCacheCache以符合JCacheCache的签名。

最后一点：基于FQN自动创建缓存对我来说似乎有点脆弱，特别是如果你有子类。 您需要对您创建的缓存以及应用它们的设置（到期，大小等）进行一些控制。

Your question is quite dense and it's not very clear what you're trying to do. What is "your existing caching" for a start? You need some way to flag the places where you actually cache things I guess. I assume you already understood you need to put a cache annotation there.

As for automatically creating the cache, I wouldn't switch to a different caching system and trying to implement that. Try to migrate first to the cache annotations with your existing cache infrastructure and then migrate to ignite.

Let's pretend you do both still. You are right CacheResolver is the way to go and it can adapt to either a regular org.springframework.cache.Cache or a javax.cache.Cache. Once you have a setup that works, I'd do the following:

In your CacheResolver implementation, inject the cache manager that has been configured Based on the method call, figure out the cache name to use (get the return type of the method, extract the FQN) Check if the cache manager has such cache. If it does, return that. If it doesn't create a new cache and add it and then return that

If you're using JCacheCacheManager, you can invoke addCache to create a new cache and then wrap the result in JCacheCache to comply with the signature of CacheResolver.

Last note: automatically creating the cache based on the FQN seems a bit fragile to me, especially if you have sub-classes. You need a bit of control on the caches you create and the settings you apply to them (expiration, size, etc).