使用Spring的AOP进行缓存在遭遇Hibernate应用时的注意点

Hibernate的实体有三种状态：Transient、Persistent、Detached，其中，只有处于Persistent的实体的变更能够被Hibernate监控到并进行相应的操作。

Hibernate对实体状态的操作，在使用了Spring的AOP进行缓存时就有了一些需要说明的问题了。 

ProductService是一个产品服务类，提供了获取所有产品getProducts()、获得指定编号产品getProduct(String)、更新指定产品价格updatePrice(String, int)三个接口。

ProductServiceAdvise是一个AOP的Advise，使用Around的方式进行拦截两个与ProductService同名的方法。简单的实例代码如下：
@Service @Transactional(propagation=Propagation.SUPPORTS)
public class ProductService {
 public Product getProduct(String productId) {
  return (Product) getSession().get(productId, Product.class);
 }
 
 @SuppressWarnings("unchecked")
 public List<Product> getProducts() {
  return getSession().getNamedQuery("GET_ALL_PRODUCTS").list();
 }
 
 @Transactional(propagation=Propagation.REQUIRED)
 public void updatePrice(String productId, int price) {
  Product product = this.getProduct(productId);
  product.setPrice(price);
 }
}

@Aspect @Service @Order(100)
public class ProductServiceAdvise {
 @Around("execution(* ProductService.getProduct(String))", argNames="productId")
 public Product getProduct(ProceedingJoinPoint pjp, String productId) throws Throwable {
  if (有缓存数据)
   return 缓存的product;
  
  Product product = (Product) pjp.proceed();
  // 增加到缓存容器中
  ....
  
  return product;
 }
}

正常情况下，ProductService.getProducts()和ProductService.getProduct(String)的调用都被相应的ProductServiceAdvise.getProducts()和ProductServiceAdvise.getProduct(String)给拦截掉，返回了ProductServiceAdvise缓存的数据，这种方式对于频繁的需要访问产品的应用提供了较好的优化，也是我们业务中常见的优化手段之一。

然而这种方式有一个陷进悄然潜伏着，不，应该说这种方式有个适用范围或者说潜规则或使用约定，即对被拦截返回的缓存数据应该进行只读操作，因为缓存返回的实体实例在Hibernate操作Session中将视为Detached，对这些实体的变更操作将不会被Session所监控到，自然也无法进行自动更新等操作了。以图解说明之：

AnotherService调用productService.getProduct(String)首先会被productServiceAdvise.getProduct(String)给拦截（图例1标注的地方），这里面有相应的判断决定是否需要调用productService.getProduct(String)（图例2标注的地方）。如果调用了，则返回的product是处于Persistent状态即可被当前Session管理的，如果没有被调用，则返回的product是detached的，是没法被当前Session管理的。

在ProductService的updatePrice(String, int)中，由于是使用了this.getProduct(String)去获取产品实例，使用this的调用在Spring的Proxy的AOP实现中，将不会被ProductServiceAdvise拦截，此时返回的始终是同一个Session中的Persistent实例，所以执行将完全正确。

但是，如果使用的AspectJ的编译方式的，由于在编译过程中在二进制代码中就加上了拦截，此时的调用将仍然被ProductServiceAdvise给拦截，执行的结果将处于一个不可预测状态了