JPA Scenario Questions 3

Posted on: April 21, 2025 Posted by: rahulgite Comments: 0

Question 1:

Before: Why is JPA being called every time even though the cache is not expired and criteria haven’t changed?

Issue:

Even though the employee data is the same, JPA repository is still being called on every request. The caching layer (like Redis or Ehcache) is not being used properly, and there’s no database query optimization in place. The data is not being retrieved from the cache as expected.

Before Example:

@Cacheable(value = "employees", key = "#criteria.hashCode()")
public List<Employee> getEmployees(EmployeeCriteria criteria) {
    return employeeRepository.findByCriteria(criteria);  // JPA query
}

In this case, the caching mechanism seems to be working, but JPA is still being called every time, even if the data hasn’t changed.

Answer:

The root cause for this behavior is that the JPA entities are being cached directly. JPA’s lazy-loaded relationships (e.g., reportingEmps) cause issues because proxy objects are cached, which still trigger database queries when accessed. When these proxies are accessed (to fetch the related entities), it results in unnecessary database calls.

Solution:

Instead of caching JPA entities, cache DTOs (Data Transfer Objects) or flattened data. These DTOs don’t rely on lazy-loading or proxy objects, eliminating the issue of unnecessary database queries when accessing cached data.

After Example:

@Cacheable(value = "employeesDTO", key = "#criteria.hashCode()")
public List<EmployeeDTO> getEmployeeDTOByCriteria(EmployeeCriteria criteria) {
    List<Employee> employees = employeeRepository.findByCriteria(criteria);
    return employees.stream()
                    .map(employee -> new EmployeeDTO(employee)) // Flatten the employee to a DTO
                    .collect(Collectors.toList());
}

In the EmployeeDTO class, you would map only the fields you need:

public class EmployeeDTO {
    private String empId;
    private String fname;
    private String lname;
    private String designation;
    private String client;
    private String status;

    public EmployeeDTO(Employee employee) {
        this.empId = employee.getEmpId();
        this.fname = employee.getFname();
        this.lname = employee.getLname();
        this.designation = employee.getDesignation();
        this.client = employee.getClient();
        this.status = employee.getStatus();
    }
}

By caching DTOs, you ensure that the data remains flat, avoiding the problems associated with lazy loading. The data is fetched only once and then cached for future use, ensuring no extra JPA queries are triggered.

Question 2:

How to add cache for employee search based on dynamic criteria in GET request without explicitly listing every field?

Issue:

The task is to cache the results of employee search based on dynamic criteria (such as empId, fname, lname, etc.), but we need a mechanism that works without manually adding each field in the cache configuration. Additionally, the cache should be updated when the criteria changes, but should not call the database again for the same criteria.

Before Example:

In this example, the method tries to filter based on multiple dynamic criteria. However, the cache key might not work correctly if the criteria are not handled dynamically.

@Cacheable(value = "employees", key = "#criteria.hashCode()")
public List<Employee> getEmployees(EmployeeCriteria criteria) {
    return employeeRepository.findByCriteria(criteria);  // JPA query
}

This implementation does not fully handle the case where the criteria can change, and the caching layer might not be fully leveraged.

Answer:

To properly add caching with dynamic criteria, you need to build a cache key dynamically and ensure that the cache is updated or invalidated whenever the criteria change. Spring’s cache abstraction allows you to specify the cache key dynamically using SpEL (Spring Expression Language). You can use a hash of the criteria object to generate unique keys for different sets of search parameters.

Solution:

You can make use of Spring’s @Cacheable annotation and configure it to use a dynamic cache key. For example, you can use a combination of criteria properties to create a unique key for each set of parameters passed. This way, the cache will store the results for each unique criteria combination.

Here’s how you can modify your method to cache based on the criteria dynamically:

After Example:

@Cacheable(value = "employees", key = "#criteria.hashCode()")
public List<Employee> getEmployeesByCriteria(EmployeeCriteria criteria) {
    return employeeRepository.findByCriteria(criteria);  // JPA query
}

In this example, criteria.hashCode() is used to create a cache key. This approach works as long as the EmployeeCriteria class implements hashCode() and equals() properly. For more complex criteria, you can use SpEL to create a custom key based on multiple attributes of the criteria object.

@Cacheable(value = "employees", key = "#criteria.empId + '-' + #criteria.fname + '-' + #criteria.lname + '-' + #criteria.status")
public List<Employee> getEmployeesByCriteria(EmployeeCriteria criteria) {
    return employeeRepository.findByCriteria(criteria);  // JPA query
}

In this case, the cache key is built based on several fields (empId, fname, lname, status) from the EmployeeCriteria. This approach ensures that each unique combination of criteria will have its own cache entry.

Handling Cache Expiry:

In some cases, the cache might need to expire or be invalidated if the underlying data changes. You can configure cache eviction to happen based on certain conditions using annotations like @CacheEvict.

@CacheEvict(value = "employees", key = "#criteria.hashCode()")
public void updateEmployee(Employee employee) {
    employeeRepository.save(employee);
}

This ensures that when data changes, the corresponding cache entry for that set of criteria is evicted.

Summary of Answers:

  1. Issue 1: JPA is still being called despite caching being in place because of lazy-loaded associations in JPA entities.
    Solution: Cache DTOs instead of JPA entities to avoid lazy-loading issues and unnecessary queries.
  2. Issue 2: How to add cache with dynamic criteria in a GET request, where the criteria fields can vary, and we want to automatically cache the result based on any combination of criteria?
    Solution: Use dynamic cache keys with SpEL (Spring Expression Language) to create unique keys for each set of criteria. The cache will store and retrieve data based on those keys. This ensures the cache is used effectively and the database isn’t queried unnecessarily.

This document now includes detailed answers and examples for both questions regarding cache implementation for dynamic criteria and JPA-related issues.

Leave a Comment