事务处理

事务管理，是应用程序中的一种牺牲性能提高数据的一致性完整性的手段。在IBM博客中有以下内容：

引用

少数应用程序极少或从来不会抛出异常。这些应用程序基于编写良好的代码、编写良好的验证例程，并经过了充分的测试，有代码覆盖支持，可以避免性能损耗和与事务处理有关的复杂性。这种类型的应用程序只需考虑事务支持的一个特性：原子性。原子性确保所有更新被当作一个单独的单元，要么全部提交，要么回滚。但是回滚或同时更新不是事务支持的惟一方面。另一方面，隔离性 将确保某一工作单元独立于其他工作单元。没有适当的事务隔离性，其他工作单元就可以访问某一活动工作单元所做的更新，即使该工作单元还未完成。这样，就会基于部分数据作出业务决策，而这会导致失败的交易或产生其他负面（或代价昂贵的）结果。

事务管理是保证服务的完整，要么提交，要么回滚，这在Linux/Unix系统中也随处可见，如果每个程序没安装成功，中途报错影响使用的话，会发生rollBack。在应用程序中也是一个道理，比如在一个服务中，重要的更新报错出错，导致业务没有实现，就有道理和理由进行回滚，撤销本次操作开始到更新操作中间的写操作，这是应用场景之一。上一场景时重要的更新，相对就有不重要的操作，比如在注册账户的过程中，需要邮件服务器向用户邮箱发送通知确认邮件，但此时邮件服务器失去连接，我们没有理由撤销用户的注册过程，所以此处我们有必要认为此次注册操作成功，至于邮件我们可以将其加入通知任务列表异步处理，这是不能进行回滚的场景之一。

REQUIRED
支持当前上下文中存在事务，如果没有事务就创建一个新的，如果有，则在当前事务下执行
SUPPORTS
支持当前上下文中存在事务，如果没有事务，就在无事务上下文下执行
MANDATORY
支持当前上下文中存在事务，如果没有事务就抛出异常
REQUIRES_NEW
产生一个新的事务，如果当前上下文中有事务就挂起原来事务
NOT_SUPPORTED
不支持当前上下文存在事务，总是在无事务上下文下执行，存在的事务会进行挂起操作
NEVER
不支持当前上下文存在事务，如果存在事务则抛出异常
NESTED
如果当前上下文中存在事务就执行一个内嵌的事务

非事务环境，一般可以用于查询，无需挂起加锁，加快查询。如果对写操作设置SUPPORTS，同时表明readonly是无效，此时没有事务，仍然会被写入。

注意事务是牺牲性能保证数据的一致性完整性，如果无需保证数据检验而又使用事务管理，反而或因为无谓加锁导致性能降低。