靠自己付出得来的糖果要比父母给的糖果甜。
在痛苦了若干天之后，总算是把事务管理这一块的大致过程搞清楚了；起因是这样的，我自己使用JDBC写了一个Dao，但是这个Dao不能进行事务回滚。从而，我发现，是因为我写的没有进行事务管理；我又想到，别人的事务管理一般都是在service层进行的；怀着这种好奇心，我就查，Spring是怎么做的。
要进行最简单的事务管理，那应该就是编程式的事务管理；使用try{}catch(){}，对于要进行持久化的语句进行异常的捕捉与处理。我觉得，最底层的事务管理也应该是这样的，声明式的事务管理不过是进行了封装而已。
既然如此，那么也就是说，Spring将异常的捕获与处理都已经进行了封装，而我们只需要进行相应的配置就可以了。这里，用到了一个Spring的核心思想——AOP面向切片思想；在了解切片思想的时候，你会遇到一个“动态代理”的概念，从而发现，动态代理是切片编程的最典型的运用；这个动态代理又是什么鬼呢？人如其名，这个动态代理说白了就是一个代理，只不过这个代理呢，是动态生成的；举个例子，茅台酒的生产厂商就一个；但是天南海北的我们都可以喝到，其中，就是用了代理；我们通过茅台酒的代理商，买到了茅台酒喝；代理商生产酒吗？不，他不生产；他所作的，只是自己拿着茅台生产厂商的酒进行售卖；如果代理商不小心买了一批假酒，被买家索赔（发生了异常，并捕获到了），代理商应该怎么做呢（捕获了异常应该怎么办呢）？这个时候代理商应当将假货退回，索要自己的钱款并购买真的酒（进行事务回滚）。
而我们的service层都做了些什么呢？当然是喝酒啦，如果酒是假的，就抛出异常让代理商捕获去；说到这里你是不是又有疑惑了？我明明是只调用了service层的方法，并没有进行事务管理的呀，他是怎么进来的？那在这儿我问你一个问题，你所调用的service层的类真的就是你写的那个类吗？恐怕你一直没考虑过这个问题吧？其实你只是一厢情愿地认为你调用的service就是你写的service，你并没有看到service是怎么实例化的。其实，你调用的service是动态代理生成的代理。这个代理对于异常是有捕获操作以及异常处理的。同时，你在service层做的事情，这个代理只是调用了，自己并不写。你写什么他就调用什么。说到这里我想你应该就明白事务管理的大致过程了。
但如果你自己去想，会发现还是有一些问题的；例如，Spring怎么知道哪些类是service层的？就因为我加了一个service的注解吗？但并不是所有的service层方法都是需要事务管理的呀，并且，并不是每一个异常我都需要进行回滚的。这个时候就需要@Transactional进行注解了。至于注解到底怎么用，就需要你自己去查查注解处理器了。很简单，这里就不做解释了。
在有了以上的共识之后，我们就可以开始Spring的配置了；首先，配置出数据源，然后配置一个事务管理器。这个时候就觉得差不多了是吧？再想想，是不是缺少一个代理生成？OK，等这三样配置齐全了之后，我们好像还缺少了一个Dao。这个Dao没什么硬性要求，可以使用Spring提供给我们的JDBCTemplate，我们也可以自己写，继承这个类就可以了。
OK，到这里就差不多了。具体的代码什么的我就不上了，百度什么的一大堆。按照自己的需求进行配置即可。我只讲我认为对的思路及原理；
最后，转载的话请标明出处。不要抹去头抹去尾就把人家痛苦好几天的成果给窃取了，这种行为极度让人憎恨！
