@CachePut helps keep your cache updated when you change data. It runs the method and then updates the cache with the new result.
@CachePut for updating cache in Spring Boot
@CachePut(value = "cacheName", key = "#key") public ReturnType methodName(Parameters) { // method logic }
value is the name of the cache to update.
key defines which cache entry to update, often using method parameters.
@CachePut(value = "users", key = "#user.id") public User updateUser(User user) { // update user in database return user; }
@CachePut(value = "products", key = "#id") public Product updateProduct(Long id, Product product) { // update product in database return product; }
This service method updates a user and then updates the cache entry for that user using @CachePut.
The cache key is the user's id, so the cache always has the latest user data.
import org.springframework.cache.annotation.CachePut; import org.springframework.stereotype.Service; @Service public class UserService { @CachePut(value = "users", key = "#user.id") public User updateUser(User user) { // Imagine this updates the user in a database System.out.println("Updating user in database: " + user); return user; // Return updated user to update cache } } record User(Long id, String name) {} // Example usage: // UserService service = new UserService(); // User updated = service.updateUser(new User(1L, "Alice Updated")); // Output: // Updating user in database: User[id=1, name=Alice Updated]
@CachePut always runs the method, unlike @Cacheable which may skip method execution if cache exists.
Make sure the method returns the updated object so the cache can store it.
Use proper keys to avoid cache collisions or wrong updates.
@CachePut updates cache after method runs.
Use it when you want fresh data in cache after changes.
It needs a cache name and a key to know what to update.
Practice
@CachePut annotation in Spring Boot?Solution
Step 1: Understand the role of @CachePut
@CachePut is used to update the cache with fresh data after the method runs, unlike @Cacheable which caches only if data is absent.Step 2: Compare options with @CachePut behavior
Only To update the cache with the method's return value after execution correctly describes updating the cache after method execution. Others describe different caching behaviors.Final Answer:
To update the cache with the method's return value after execution -> Option AQuick Check:
@CachePut updates cache after method runs [OK]
- Confusing @CachePut with @Cacheable
- Thinking @CachePut clears cache
- Assuming it caches only if absent
@CachePut to update a cache named "users" with a key based on the method parameter id?Solution
Step 1: Recall correct attribute names for @CachePut
The correct attribute for cache name is 'value' or 'cacheNames', and SpEL expressions for keys use '#'.Step 2: Analyze each option's syntax
@CachePut(value = "users", key = "#id") uses 'value' and '#id' correctly. Others use incorrect attribute names or miss the '#' for SpEL.Final Answer:
@CachePut(value = "users", key = "#id") -> Option BQuick Check:
Use 'value' and '#param' for key in @CachePut [OK]
- Using wrong attribute names like cacheName or cache
- Missing '#' in key expression
- Using plain string instead of SpEL for key
@CachePut(value = "products", key = "#product.id")
public Product updateProduct(Product product) {
product.setPrice(product.getPrice() + 10);
return product;
}
What will be the effect on the cache when this method is called with a product having id=5 and price=100?Solution
Step 1: Understand @CachePut behavior on method call
@CachePut updates the cache entry with the key specified after the method returns the updated object.Step 2: Analyze the method logic and cache key
The method increases price by 10 and returns the product. The key is product.id which is 5, so cache key 5 is updated with product price 110.Final Answer:
The cache entry with key 5 is updated with the product having price 110 -> Option CQuick Check:
@CachePut updates cache key with returned value [OK]
- Thinking cache key changes to price
- Assuming cache entry is removed
- Confusing @CachePut with @Cacheable
@CachePut:
@CachePut(value = "orders", key = "#order.id")
public Order updateOrder(Order order) {
// missing return statement
}
What is the problem with this code?Solution
Step 1: Check method return requirement for @CachePut
@CachePut requires the method to return a value to update the cache with that value.Step 2: Identify missing return statement issue
The method lacks a return statement, so no value is returned to update the cache, causing runtime issues.Final Answer:
The method does not return a value, so cache cannot be updated -> Option DQuick Check:
@CachePut needs method return to update cache [OK]
- Forgetting to return the updated object
- Confusing cache name attribute
- Using @Cacheable instead of @CachePut incorrectly
@CachePut to achieve this, assuming the method signature is public User updateEmail(Long userId, String newEmail)?Solution
Step 1: Verify correct cache name and key usage
@CachePut(value = "users", key = "#userId") public User updateEmail(Long userId, String newEmail) { User user = userRepository.findById(userId); user.setEmail(newEmail); userRepository.save(user); return user; } uses 'value = "users"' and key '#userId', correctly identifying the cache and key.Step 2: Check method return and update logic
@CachePut(value = "users", key = "#userId") public User updateEmail(Long userId, String newEmail) { User user = userRepository.findById(userId); user.setEmail(newEmail); userRepository.save(user); return user; } returns the updated User object, which is necessary for @CachePut to update the cache. Other options either use wrong key, no return, or missing cache name.Final Answer:
@CachePut(value = "users", key = "#userId") public User updateEmail(Long userId, String newEmail) { User user = userRepository.findById(userId); user.setEmail(newEmail); userRepository.save(user); return user; } -> Option AQuick Check:
Return updated object and use correct cache name and key [OK]
- Using wrong key expression
- Not returning updated object
- Omitting cache name in annotation
Ready to prove it?
Pass the test and this pattern moves unknown
