还在学Hibernate，后续一大堆概念刚接触需要理解。觉得-——事务——这个概念不是很好理解，所以发上来记录一下。
首先说点千篇一律的东西。概念和特性都是随处可见的，无论哪里都很容易找到，关键是你如何去理解它。
概念：事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务通常由高级数据库操纵语言或编程语言（如SQL，C++或Java）书写的用户程序的执行所引起，并用形如begin transaction和end transaction语句（或函数调用）来界定。事务由事务开始(begin transaction)和事务结束(end transaction)之间执行的全体操作组成。
例如：在关系数据库中，一个事务可以是一条SQL语句，一组SQL语句或整个程序。
特性：事务是恢复和并发控制的基本单位。
事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。
原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。
一致性（consistency）。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。
隔离性（isolation）。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
持久性（durability）。指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。
————————————————————————————————————————————————————————————————————————
为什么引入“事务”这个概念？
--->就像所有的文学，来自与生活，却又高于生活一样。事务的概念同样的来自于生活，引入“事务”肯定是为了解决某种问题，不然，谁愿意干这么无聊的事情呢？
现实里好比银行转账一样，当从一个帐户转出一部分钱之后，就必须在另一个帐户中存入相同数目的钱，若是转出钱之后，事务中止了，没有在另一个帐户中存钱，那么钱就不翼而飞了（事务的原子性），这事肯定是搁在谁身上都是不干的事情。而在软件中由于“事务”与数据库相关，在这个数字化时代，一切即数字，当然包括钱了。这么重要的东西一定得有所保障，既然“事务”能为它提供保障，那么引入它也是理所当然的。
如何理解事务的原子性？
--->原子性在最初在物理上解释为：不可再分割的。
可是在这里却感觉与物理上的理解有所不同，因为它把你随便一个事务都划分为原子性的，且它的原子性更偏向于结果的唯一性：要么成功，要么失败。
我们可知在Hibernate中由session.beginTransaction();语句我们可以自定义一个事务，而用session.endtransaction（）来告诉该事务的结束，那么至于这两者之间的操作当然可以由你自己定义了。这个事务可大可小但是结果只有一个。
事务是否可以什么都不做？还是说一定要与数据库联系起来？
--->由事务的定义：“事务是访问并可能更新数据库中各种数据项的一个程序执行单元"可知，事务首先要实现对数据库的访问。这样来看，事务是不可能什么都不做的。因此事务的存在确实与数据库相关。
事务的一致性？
--->这个问题不是很好理解。一致性与原子性关系密切。
假如有一个产品表和一个产品明细表，是父子关系，当我们添加产品表的时候，一定要添加产品明细表的资料，如果我们只是添加了产品表没有添加产品明细，这样就会是数据不一致，混乱，这里我们就要用到事务了。
事务的隔离性？
--->这个比较好理解，若学过多线程的话就能理解多线程为什么要引入锁机制了。而同样为了解决事务的并发问题而引入的事务的隔离级别，数据库和应用程序都可以设置隔离级别。
事务的持久性？
--->假若你的事务是去银行存钱，那么你总不希望你刚刚提交完存钱请求之后（即事务已提交成功），由于突然的故障而让你的金钱“失联”吧！这就是事务的持久性。
这里有个问题，如果我的“事务”过程只是存钱，那么，根据以上的栗子，存钱完后——即事务已提交成功——那么是不是意味着事务已经完成了呢？那么后续的动作是不是就不是事务的范围之内了呢？存钱的事务完成，动作就传递给了数据库，那么于数据库的动作不再我刚刚那个“事务”当中呀！确实有待多了解。
事务与线程的同和异？