小心，SpringAOP声明式事务的一个缺陷
?
????? 现在看来，这种抽象同样带了一个缺陷，那就是抹杀了Cglib能够直接创建普通类的增强子类的能力，Spring相当于把Cglib动态生成的子类，当普通的代理类了，这也是为什么会创建两个对象的原因。下图显示了Spring的AOP代理类的实际调用过程：
?
????
???? 
?
????? 因此，从上面的分析可以看出，methodB没有被AopProxy通知到，导致最终结果是：被Spring的AOP增强的类，在同一个类的内部方法调用时，其被调用方法上的增强通知将不起作用。
????
????? 而这种结果，会造成什么影响呢：
????? 1：内部调用时，被调用方法的事务声明将不起作用
????? 2：换句话说，你在某个方法上声明它需要事务的时候，如果这个类还有其他开发者，你将不能保证这个方法真的会在事务环境中
????? 3：再换句话说，Spring的事务传播策略在内部方法调用时将不起作用。不管你希望某个方法需要单独事务，是RequiresNew，还是要嵌套事务，要Nested，等等，统统不起作用。
????? 4：不仅仅是事务通知，所有你自己利用Spring实现的AOP通知，都会受到同样限制。。。。
?
[解难]
?????
????? 问题的原因已经找到，其实，我理想中的AOP实现，应该是下面这样：
?????
???? 
?????
????? 只要一个Cglib增强对象就好，对于Java代理方式，我的选择是毫不犹豫的抛弃。
?
????? 至于前面的事务问题，只要避开Spring目前的AOP实现上的限制，要么都声明要事务，要么分开成两个类，要么直接在方法里使用编程式事务，那么一切OK。
