jetcache Documentation

File: docs/EN/AdvancedCacheAPI.md Copy Chapter

CacheBuilder

The CacheBuilder provide a way to construct Cache instance use your own code, See Here.
CacheBuilder are useful if you work without Spring, otherwise you may not use it directly.

asynchronous API

All CacheResult returned by uppercase method support asynchronous access (since 2.2).
Presently asynchronous result only provide in redis-lettuce implementation.
Other implementations such as Tair, Jedis will block during uppercase method call.
But all the api are same.

For example:

CacheGetResult r = cache.GET(userId);

If you use Tair, Jedis the GET operation will block until cache access finished.
However the GET method will return immediately if you use lettuce to access redis,
any following call of r.isSuccess() or r.getValue() or r.getMessage() will block. To avoid this you can:

CompletionStage<ResultData> future = r.future();
future.thenRun(() -> {
    if(r.isSuccess()){
        System.out.println(r.getValue());
    }
});

The above code will execute callback in the thread which execute the asynchronous operation.
CompletionStage is a new feature in Java 8, read related documents if you are not familiar with it.
Note do not call any block method in the callback, since the callback is probably run in event-loop thread.

Some lowercase API can also get the advantage of asynchronous capability since they have no return value (in a asynchronous enabled backend such as lettuce).
For instance put and removeAll will return immediately, but get will not because get method need return a value.

Auto load（read through）

LoadingCache provide auto load capability (since 2.2). It is based on decorator pattern and implements Cache interface.
If a CacheBuilder has a loader, then its buildCache method will return a LoadingCache wrapper.
For example :

Cache<Long,UserDO> userCache = LinkedHashMapCacheBuilder.createLinkedHashMapCacheBuilder()
                .loader(key -> loadUserFromDatabase(key))
                .buildCache();

The get and getAll method of LoadingCache will call the loader when cache miss.
If any exception throws in the loader, get and getAll will throw CacheInvokeException.

Notice:

1. uppercase method such as GET and GET_ALL only operate with cache and do not invoke the loader.
2. loader should be install on MultiLevelCache if you use multi level cache, do not install it on the cache underneath.

Unfortunately, we can't set the loader on @CreateCache because only constant is permit for the attribute of an annotation.
So we use the follow code instead:

@CreateCache
private Cache<Long,UserDO> userCache;

@PostConstruct
public void init(){
    userCache.config().setLoader(this::loadUserFromDatabase);
}

@CreateCache always return a LoadingCache wrapper, so we can set a loader in the init method and take effect immediately.

Auto refreshment

The RefreshCache provide auto refreshment capability (since 2.2).
It is based on decorator pattern and implements Cache interface.
The buildCache method of CacheBuilder will return a RefreshCache wrapper when loader and refreshPolicy are both be set.

CacheBuilder usage:

RefreshPolicy policy = RefreshPolicy.newPolicy(1, TimeUnit.MINUTES)
                .stopRefreshAfterLastAccess(30, TimeUnit.MINUTES);
Cache<String, Long> orderSumCache = LinkedHashMapCacheBuilder
                .createLinkedHashMapCacheBuilder()
                .loader(key -> loadOrderSumFromDatabase(key))
                .refreshPolicy(policy)
                .buildCache();

The above code specify that every key-value pair should refresh every 1 minute since first access.
The refreshment of one key-value pair stops if this key does not be access in 30 minutes.
If the backend cache system is a remote cache (or MultiLevelCache with a remote cache as last layer),
the refreshment is global exclusive, so it avoid two or more servers refresh same key concurrently (implements using tryLock in Cache).

Similar with LoadingCache, we init refresh policy in the init method when using with @CreateCache:

@CreateCache
private Cache<String, Long> orderSumCache;

@PostConstruct
public void init(){
    RefreshPolicy policy = RefreshPolicy.newPolicy(1, TimeUnit.MINUTES)
                          .stopRefreshAfterLastAccess(30, TimeUnit.MINUTES);
    orderSumCache.config().setLoader(this::loadOrderSumFromDatabase);
    orderSumCache.config().setRefreshPolicy(policy);
}

File: docs/EN/Builder.md Copy Chapter

Annotations such as @Cached and @CreateCache are based on Spring Framework 4.0 or above.
You can use JetCache API to create, manage, monitor Cache instance.

Create Cache

Similar to guava/caffeine cache. For example, the below code create a LinkedHashMapCache instance:

Cache<String, Integer> cache = LinkedHashMapCacheBuilder.createLinkedHashMapCacheBuilder()
                .limit(100)
                .expireAfterWrite(200, TimeUnit.SECONDS)
                .buildCache();

Create RedisCache (using jedis):

GenericObjectPoolConfig pc = new GenericObjectPoolConfig();
        pc.setMinIdle(2);
        pc.setMaxIdle(10);
        pc.setMaxTotal(10);
        JedisPool pool = new JedisPool(pc, "localhost", 6379);
Cache<Long, OrderDO> orderCache = RedisCacheBuilder.createRedisCacheBuilder()
                .keyConvertor(Fastjson2KeyConvertor.INSTANCE)
                .valueEncoder(JavaValueEncoder.INSTANCE)
                .valueDecoder(JavaValueDecoder.INSTANCE)
                .jedisPool(pool)
                .keyPrefix("orderCache")
                .expireAfterWrite(200, TimeUnit.SECONDS)
                .buildCache();

Note: JetCache 2.8.x enables the deserialization security filter by default. If your cached values contain custom classes (e.g. OrderDO above), you need to configure the filter allow list before creating the cache, otherwise deserialization will fail:

java Copy

DecodeFilter.getDefault().addAllowPatterns("com.yourcompany.");

See the "Deserialization Filter Configuration" section in the configuration docs for details.

Multi level cache

Cache multiLevelCache = MultiLevelCacheBuilder.createMultiLevelCacheBuilder()
      .addCache(memoryCache, redisCache)
      .expireAfterWrite(100, TimeUnit.SECONDS)
      .buildCache();

You can even build cache more than two level.

Monitor

Cache orderCache = ...
CacheMonitor orderCacheMonitor = new DefaultCacheMonitor("OrderCache");
orderCache.config().getMonitors().add(orderCacheMonitor); // jetcache 2.2+, or call builder.addMonitor() before buildCache()
// Cache<Long, Order> monitedOrderCache = new MonitoredCache(orderCache, orderCacheMonitor); //before jetcache 2.2
int resetTime = 1;
boolean verboseLog = false;
DefaultCacheMonitorManager cacheMonitorManager = new DefaultCacheMonitorManager(resetTime, TimeUnit.SECONDS, verboseLog);
cacheMonitorManager.add(orderCacheMonitor);
cacheMonitorManager.start();

Each CacheMonitor used for exactly one Cache instance.
After start, DefaultCacheMonitorManager outputs statistics every resetTime using slf4j (see Statistics).

The constructor parameter of DefaultCacheMonitor will be used as cache name in output table.

You can add to CacheMonitor to every Cache instance in MultiLevelCache,
so each cache in multi level cache is monitored.

The output format can be customized using this constructor:

public DefaultCacheMonitorManager(int resetTime, TimeUnit resetTimeUnit, Consumer<StatInfo> statCallback)

File: docs/EN/CacheAPI.md Copy Chapter

Introduce

The core concept of JetCache is the com.alicp.jetcache.Cache(hereinafter called Cache) interface, it provides some API similar like javax.cache.Cache in JSR107.
The reason that JetCache does not implements JSR107 includes:

1. We want that the API of JetCache are more simpler and easy to use than JSR107.
2. Some operation defined in javax.cache.Cache are difficult to implement efficiently in some specific distributed cache system (eg. some atomic operation and removeAll()).
3. Implements whole JSR107 needs a lots of work.

JSR107 style API

The follows methods in JetCache Cache interface are same with those in javax.cache.Cache except that
the methods in Cache never throws exception.

V get(K key)
void put(K key, V value);
boolean putIfAbsent(K key, V value); //MultiLevelCache do not support this method
boolean remove(K key);
<T> T unwrap(Class<T> clazz);
Map<K,V> getAll(Set<? extends K> keys);
void putAll(Map<? extends K,? extends V> map);
void removeAll(Set<? extends K> keys);

JetCache Cache API

V computeIfAbsent(K key, Function<K, V> loader)
V computeIfAbsent(K key, Function<K, V> loader, boolean cacheNullWhenLoaderReturnNull)
V computeIfAbsent(K key, Function<K, V> loader, boolean cacheNullWhenLoaderReturnNull, long expire, TimeUnit timeUnit)

If there is a value associated with the key, return the value,
otherwise use the loader load the value and update the cache, then return the value.
The cacheNullWhenLoaderReturnNull parameter indicate whether null value returned by loader should put into cache.
The expire and timeUnit specifies the TTL (will overrides defaults) of the KV pair when update the cache.
Load time are recorded with these methods.

void put(K key, V value, long expire, TimeUnit timeUnit)

The put opperation. expire and timeUnit specifies the TTL (will overrides defaults).

AutoReleaseLock tryLock(K key, long expire, TimeUnit timeUnit)
boolean tryLockAndRun(K key, long expire, TimeUnit timeUnit, Runnable action)

Try to get a lock of the key in non-block way.
Return a instance of AutoReleaseLock if there is no lock on the specified key, or else null.
If the Cache is an in-memory implementation, the lock is a local lock in the JVM,
or else it's a non-strict distributed lock.
The expire time of the lock specified by expire and timeUnit.
MultiLevelCache use the last level to acquire the lock.
Here is an example:

// use try-with-resource to auto release the lock
  try(AutoReleaseLock lock = cache.tryLock("MyKey",100, TimeUnit.SECONDS)){
     if(lock != null){
        // do something
     }
  }

Here is a simpler way that you never forget if(lock != null):

boolean hasRun = cache.tryLockAndRun("MyKey",100, TimeUnit.SECONDS, () -> {
    // do something
  });

When the cache system is distributed, the tryLock will carefully auto retry when network fails, and it never release a lock that the current machine doesn't hold. Using tryLock or tryLockAndRun are much easier than make your own lock based on a cache system.
Be keep in mind that the distributed lock based on a cache system is non-strict,
if you need strict distributed lock you should consider other framework like Zoo Keeper.

Upper case API

Operation like V get(K key) are convenient but it can not tell more information when it returns null.
So JetCache provide some more operation which return a CacheResult object like belows:

CacheGetResult<V> GET(K key);
MultiGetResult<K, V> GET_ALL(Set<? extends K> keys);
CacheResult PUT(K key, V value);
CacheResult PUT(K key, V value, long expireAfterWrite, TimeUnit timeUnit);
CacheResult PUT_ALL(Map<? extends K, ? extends V> map);
CacheResult PUT_ALL(Map<? extends K, ? extends V> map, long expireAfterWrite, TimeUnit timeUnit);
CacheResult REMOVE(K key);
CacheResult REMOVE_ALL(Set<? extends K> keys);
CacheResult PUT_IF_ABSENT(K key, V value, long expireAfterWrite, TimeUnit timeUnit);

The name of these method are all uppercase. The usage are more complex and powerful:

CacheGetResult<OrderDO> r = cache.GET(orderId);
if( r.isSuccess() ){
    OrderDO order = r.getValue();
} else if (r.getResultCode() == CacheResultCode.NOT_EXISTS) {
    System.out.println("cache miss:" + orderId);
} else if(r.getResultCode() == CacheResultCode.EXPIRED) {
    System.out.println("cache expired:" + orderId));
} else {
    System.out.println("cache get error:" + orderId);
}

File: docs/EN/Compatibility.md Copy Chapter

spring compatibility

jetcache tested with below spring/spring-boot versions

compatible change notes

2.8.0 Copy Chapter

• Java 17 is now the minimum required version

• areaInCacheName default value is now false (was true in versions prior to 2.8.0).

• kryo4 is no longer supported, com.esotericsoftware:kryo is upgraded to 5.x. The KRYO constant in SerialPolicy now uses kryo5 implementation internally. kryo4 serialized data is not compatible with kryo5, wait for old cache entries to expire or clear cache before upgrading

• Removed fastjson1 support, fastjson key convertor now uses fastjson2 internally. If you need fastjson1, add the dependency yourself and implement a custom KeyConvertor

• Removed Spring XML namespace support (<jetcache:xxx> tags in XML configuration are no longer available)

• Added deserialization filter mechanism (enabled by default). This is a breaking change — if your cached values contain custom classes not in the default allowed list, deserialization (or serialization) will fail immediately after upgrading.

  Upgrade steps: Since older versions do not have this configuration option, pre-configuration before upgrading is not possible. Two recommended approaches:

  Option 1: Add decodeFilterAllowPatterns configuration at the same time as upgrading JetCache, including the package names of your custom classes in the allow list. For example:

  yaml Copy

  jetcache:
    decodeFilterAllowPatterns:
      - com.yourcompany.

  Option 2: Disable the filter during upgrade (same behavior as 2.7):

  yaml Copy

  jetcache:
    decodeFilterEnabled: false

  See the "Deserialization Filter Configuration" section in the configuration docs for the list of default allowed packages and detailed setup instructions.

2.7.4 Copy Chapter

• use spring-boot 3.1.3, spring-framework 6.0.11, slf4j-api 2.x as default
• remove javax.annotation:javax.annotation-api, if you use @PostConstruct, you may need to add this dependency by yourself

2.7.2 Copy Chapter

• update encoder/decoder of redisson, not compatible with 2.7.1

2.7.0 Copy Chapter

• jetcache-redis depends on jedis4，springdata(jedis) depends on jedis3, can't use together
• encoder/decoder now support kryo4 and kryo5, in yml "kryo" is kryo4，"kryo5" is kryo5. the kryo4 and kryo5 is not compatible.
  • in maven kryo4 is com.esotericsoftware:kryo, kryo5 is com.esotericsoftware.kryo:kryo5
  • kryo4 and kryo5 can be used together
  • notice that version of com.esotericsoftware:kryo can be set to 5.x.x
• use lettuce to connect redis cluster need specify "mode=cluster" in yml
• default key convertor change to "fastjson2", fastjson2 and fastjson can be used together, fastjson(not fastjson2)/kryo/kryo5/mvel is now optional in maven
• if not use spring boot, add @Import(JetCacheBaseBeans.class), and remove old configProvider bean definition. see docs for detail example.
• change GlobalCacheConfig.areaInCacheName default value to false (has bug, default value may still be true), need to add areaInCacheName=false

2.6.0 Copy Chapter

• GET/GET_ALL method of RefreshCache will not trigger auto refresh
• lettuce 4 is not supported
• jedis 2.9 is not supported

2.5.0 Copy Chapter

• ClassCastException may occurs when upgrade directly from versions <=2.3.3 and MultiLevelCache(or cacheType=CacheType.BOTH) is used. To solve this problem, upgrade to 2.4.4 and deploy it to product env first, then upgrade to 2.5.0 or above.
• Annotations on sub classes will override annotations on interfaces and super class.

File: docs/EN/Config.md Copy Chapter

Here is an example of yml config file in Spring Boot:

jetcache:
  statIntervalMinutes: 15
  areaInCacheName: false
  hidePackages: com.alibaba
  local:
    default:
      type: caffeine
      limit: 100
      keyConvertor: fastjson2 #other choose：fastjson(same as fastjson2)/jackson/jackson3
      expireAfterWriteInMillis: 100000
    otherArea:
      type: linkedhashmap
      limit: 100
      keyConvertor: none
      expireAfterWriteInMillis: 100000
  remote:
    default:
      type: redis
      keyConvertor: fastjson2 #other choose：fastjson(same as fastjson2)/jackson/jackson3
      broadcastChannel: projectA
      valueEncoder: java #other choose：kryo/kryo5
      valueDecoder: java #other choose：kryo/kryo5
      poolConfig:
        minIdle: 5
        maxIdle: 20
        maxTotal: 50
      host: ${redis.host}
      port: ${redis.port}
    otherArea:
      type: redis
      keyConvertor: fastjson2 #other choose：fastjson(same as fastjson2)/jackson/jackson3
      broadcastChannel: projectA
      valueEncoder: java #other choose：kryo/kryo5
      valueDecoder: java #other choose：kryo/kryo5
      poolConfig:
        minIdle: 5
        maxIdle: 20
        maxTotal: 50
      host: ${redis.host}
      port: ${redis.port}

You can configure GlobalCacheConfig directly without Spring Boot. It's similar. See getting started tutorial.

The description of configuration listed in the below table:

The ${area} of the above table is the area attribute of @Cached and @CreateCache. Note that the default value of area attribute of the two annotation is "default".

There are multi place which the write expire time can be set:

1. if a method like put in Cache interface sets expire, then use it.
2. if not set in method like put, use default expire of the Cache instance
3. the default expire of the Cache instance can be set in attribute on @CreateCache or @Cached, if not, JetCache use global config defaultExpireInMillis defined in yml(for instance @Cached(cacheType=local) use jetcache.local.default.expireAfterWriteInMillis), if there is not defined yet then use infinity.

Deserialization Filter Configuration Copy Chapter

JetCache 2.8.x enables deserialization filter by default. The filter maintains both an allow list and a deny list. The deny list takes the highest priority and cannot be overridden by user-defined allow patterns.

The default allow list:

If your cached values contain custom classes, you need to configure the filter:

jetcache:
  decodeFilterEnabled: true  # default true, can set false to disable
  decodeFilterAllowPatterns:
    - com.example.          # prefix match: all classes under com.example and subpackages
    - org.myapp.dto         # package match: direct classes in org.myapp.dto (no subpackages)
    - org.myapp.dto.UserDTO # exact match: only this specific class
  decodeFilterDenyPatterns:
    - com.example.internal.      # block this package and its subpackages
    - org.myapp.dto.SecretDTO    # block one specific class

Filter rules: The built-in deny list includes known deserialization gadget chains (e.g. Commons Collections, Spring AOP, Hibernate, Groovy, JNDI/RMI, C3P0, etc.), dangerous classes like java.lang.Runtime and ProcessBuilder, and JDK internal packages like com.sun. and sun.. Deny patterns cannot be overridden by allow rules. If necessary, you can remove specific deny patterns via DecodeFilter.getDefault().removeDenyPatterns(...) (evaluate security risks yourself).

Pattern matching rules:

• Prefix match (ends with .): matches all classes in the package and all subpackages. For example, com.example. matches com.example.Foo, com.example.sub.Bar, etc.
• Package match (no trailing ., not a full class name): matches only classes directly in the package, excluding subpackages. For example, com.example matches com.example.Foo but not com.example.sub.Bar. The default allow list uses this mode for java.lang and java.net.
• Exact match (full class name): matches only one specific class. For example, org.myapp.dto.UserDTO matches only org.myapp.dto.UserDTO.

Tip: If your custom classes are spread across multiple packages, prefix match (ending with .) is the most convenient option.

You can also configure programmatically (non-Spring Boot scenario):

DecodeFilter filter = DecodeFilter.getDefault();
filter.addAllowPatterns("com.example.");

If a class is blocked during deserialization, an ERROR log is emitted (containing the rejected class name and configuration examples), and an exception is thrown. Kryo and JSON paths throw DecodeFilterException; Java serialization throws InvalidClassException (JDK internal behavior).

Notes:

• JDK dynamic proxy classes (e.g. jdk.proxy1.$Proxy0) are not in the default allow list. If you cache proxy objects (e.g. Spring AOP proxies), add an allow rule (e.g. jdk.proxy.).
• Packages like java.rmi., javax.naming., java.lang.reflect., javax.script., javax.management. are in the built-in deny list — adding allow rules cannot override them. Packages like java.io, java.beans (except EventHandler) are not in the allow list but also not in the deny list; they can be added via decodeFilterAllowPatterns or addAllowPatterns.
• If you need to block additional packages or classes beyond the built-in deny list, add them via decodeFilterDenyPatterns or addDenyPatterns.

File: docs/EN/CreateCache.md Copy Chapter

CacheManager

use CacheManager to create Cache instance, it returns same Cache instance with @Cached if area and name equals.

notice: in jetcache 2.7 CreateCache annotation is deprecated, use CacheManager.getOrCreateCache(QuickConfig) instead

example:

@Autowired
private CacheManager cacheManager;
private Cache<String, UserDO> userCache;

@PostConstruct
public void init() {
    QuickConfig qc = QuickConfig.newBuilder("userCache")
        .expire(Duration.ofSeconds(100))
        .cacheType(CacheType.BOTH) // two level cache
        .syncLocal(true) // invalidate local cache in all jvm process after update
        .build();
    userCache = cacheManager.getOrCreateCache(qc);
}

CreateCache annotation

You can use @CreateCache annotation to create and configure a Cache instance in a Spring Bean.
For Example:

@CreateCache(expire = 100)
private Cache<Long, UserDO> userCache;

The attributes of @CreateCache

Default values

There are some attributes in the above table has no default value. JetCache will use global config value when you not specify the value in annotation.
See Configuration details for more information about global config.

File: docs/EN/Embedded.md Copy Chapter

The keyConvertor is optional if you are using Cache API in jetcache-core,
the local cache uses equals to identity the key.
You must specify keyConvertor if you use annotations in jetcache-anno, such as @Cached and @CreateCache.

There are two local cache (class AbstractEmbeddedCache) implementation in JetCache.

LinkedHashMapCache

LinkedHashMapCache is a simple implementation in JetCache.
It is built on java.util.LinkedHashMap and supports LRU algorithm.

Cache<Long, OrderDO> cache = LinkedHashMapCacheBuilder.createLinkedHashMapCacheBuilder()
                .limit(100)
                .expireAfterWrite(200, TimeUnit.SECONDS)
                .buildCache();

CaffeineCache

CaffeineCache is built on caffeine cache.

Cache<Long, OrderDO> cache = CaffeineCacheBuilder.createCaffeineCacheBuilder()
                .limit(100)
                .expireAfterWrite(200, TimeUnit.SECONDS)
                .buildCache();

File: docs/EN/GettingStarted.md Copy Chapter

Create Cache instance

Create a Cache instance using @CreateCache annotation with default TTL 100 seconds.

@Autowired
private CacheManager cacheManager;

private Cache<Long, UserDO> userCache;

@PostConstruct
public void init() {
    QuickConfig qc = QuickConfig.newBuilder("userCache") // name used in statistical information
        .expire(Duration.ofSeconds(100))
        //.cacheType(CacheType.BOTH) // create two level cache
        //.localLimit(100) // limit for local cache elements, only used for CacheType.LOCAL and CacheType.BOTH
        //.syncLocal(true) // invalidate local cache in other JVM after updates, only used for CacheType.BOTH, need set broadcastChannel in configuration. 
        .build();
    userCache = cacheManager.getOrCreateCache(qc);
}

Then use Cache instance like a map:

UserDO user = userCache.get(123L);
userCache.put(123L, user);
userCache.remove(123L);

Create method cache

@Cached can be used to add method cache for a method.
JetCache use Spring AOP to generate proxy to support method cache。
The @Cached annotation can be add on interface method or class method, but the interface or class must defined as a Spring bean.

public interface UserService {
    @Cached(name="UserService.getUserById", expire = 3600)
    User getUserById(long userId);
}

Basic configuration (using Spring Boot)

This example using jedis to accessing redis(or you can consider using lettuce client):

POM

<dependency>
    <groupId>com.alicp.jetcache</groupId>
    <artifactId>jetcache-starter-redis</artifactId>
    <version>${jetcache.latest.version}</version>
</dependency>

Create a Spring Boot style configuration file application.yml and put it into the resource dir.

jetcache:
  statIntervalMinutes: 15
  areaInCacheName: false
  local:
    default:
      type: linkedhashmap
      keyConvertor: fastjson2 #other choose：fastjson(same as fastjson2)/jackson/jackson3
  remote:
    default:
      type: redis
      keyConvertor: fastjson2 #other choose：fastjson(same as fastjson2)/jackson/jackson3
      broadcastChannel: projectA
      valueEncoder: java
      valueDecoder: java
      poolConfig:
        minIdle: 5
        maxIdle: 20
        maxTotal: 50
      host: 127.0.0.1
      port: 6379

Note: JetCache 2.8.x enables the deserialization security filter by default. The configuration above uses the java serializer. If your cached values contain custom classes (e.g. UserDO, OrderDO, etc.), deserialization will be blocked by the filter. You need to add decodeFilterAllowPatterns to allow your classes:

yaml Copy

jetcache:
  decodeFilterAllowPatterns:
    - com.company.mypackage.  # allow all classes under this package

If you also need to block additional packages or classes, configure decodeFilterDenyPatterns. See the "Deserialization Filter Configuration" section in the configuration docs for details. You can set jetcache.decodeFilterEnabled: false to disable the filter temporarily (NOT recommended in production).

Then create the application class of Spring Boot:

package com.company.mypackage;

import com.alicp.jetcache.anno.config.EnableCreateCacheAnnotation;
import com.alicp.jetcache.anno.config.EnableMethodCache;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
@EnableMethodCache(basePackages = "com.company.mypackage")
@EnableCreateCacheAnnotation
public class MySpringBootApp {
    public static void main(String[] args) {
        SpringApplication.run(MySpringBootApp.class);
    }
}

The @EnableMethodCache and @EnableCreateCacheAnnotation annotation activate @Cached and @CreateCache respectively.
Other code are same with standard Spring Boot Application. This class can run directly using main method.

Basic configuration (without Spring Boot)

This example using jedis to accessing redis:

<dependency>
    <groupId>com.alicp.jetcache</groupId>
    <artifactId>jetcache-anno</artifactId>
    <version>${jetcache.latest.version}</version>
</dependency>
<dependency>
    <groupId>com.alicp.jetcache</groupId>
    <artifactId>jetcache-redis</artifactId>
    <version>${jetcache.latest.version}</version>
</dependency>

The following code configure JetCache using hand coding, then you can use @CreateCache and @Cached in you beans.

/* Detailed source-code truncated for AI context efficiency. */

read more

• Initiate Cache instance using CacheManager
• Basic Cache API
• Method cache using annotation(@Cached, @CacheUpdate, @CacheInvalidate)
• Configuration details

File: docs/EN/MethodCache.md Copy Chapter

The method caching in JetCache is similar like Spring Cache. JetCache provide naitve TTL support and two level cache support.

Add @Cached on a method of a Spring bean to enable method caching. Since 2.4 @CacheUpdate and @CacheInvalidate are introduced for removing and updating method cache. You can even add the annotation on the interface that the bean implements.

public interface UserService {
    @Cached(name="userCache.", key="#userId", expire = 3600)
    User getUserById(long userId);

    @CacheUpdate(name="userCache.", key="#user.userId", value="#user")
    void updateUser(User user);

    @CacheInvalidate(name="userCache.", key="#userId")
    void deleteUser(long userId);
}

the key and value attribute use SpEL script. To enable use parameter name such as key="#userId", the -parameters javac compiler flag should be set, otherwise use index to access parameters like key="args[0]".

The attributes of @Cached are similar with @CreateCache except @Cached has more attributes:

@CacheInvalidate attribute table:

@CacheUpdate attribute table:

Note that remote cache operation related to @CacheUpdate and @CacheInvalidate may fail, so it is important to set the '''expire''' attribute.

@CacheRefresh attribute table:

@CachePenetrationProtect:

This annotation used to synchronize concurrent cache loading operation.
Currently it only take effect only in each single JVM, that is, in one JVM there is only one thread load for same key,
other threads wait for the result.

There are some attributes in the above table has no default value. JetCache will use global config when you not specify the value in annotation.
See Configuration details for more information about global config.