JavaEE5学习笔记01-JTA和数据库事务---2
下面我们再看加了JTA处理后的代码如下
| UserTransaction userTransaction = null;
try { Context ctx = new InitialContext(); DataSource ds1 = (DataSource) ctx.lookup("java:/oracle1"); DataSource ds2 = (DataSource) ctx.lookup("java:/oracle2");
userTransaction = (UserTransaction) ctx.lookup("UserTransaction");
Connection connection1 = ds1.getConnection(); Connection connection2 = ds2.getConnection();
userTransaction.begin();
Statement statement1 = connection1.createStatement(); Statement statement2 = connection2.createStatement();
String sql1 = "insert into jimmy_user values(4,'谈无欲')"; String sql2 = "insert into jimmy_user values(3,'傲笑红尘')";
int sun1 = statement1.executeUpdate(sql1); int sun2 = statement2.executeUpdate(sql2);
statement1.close(); connection1.close();
statement2.close(); connection2.close();
} catch (NamingException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (NotSupportedException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (SystemException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (SQLException e) { // TODO Auto-generated catch block e.printStackTrace(); try { userTransaction.rollback(); } catch (IllegalStateException e1) { // TODO Auto-generated catch block e1.printStackTrace(); } catch (SecurityException e1) { // TODO Auto-generated catch block e1.printStackTrace(); } catch (SystemException e1) { // TODO Auto-generated catch block e1.printStackTrace(); } } |
执行之后，“谈无欲”与“傲笑红尘”都没进入数据库，全局事务回滚了。
1. XA规范的全局事务中间件
XA是分布式事务处理的规范，具体的实现是不同的数据库厂商自己实现的，mysql驱动目前不支持XA规范。
| 通常情况下，交易中间件与数据库通过XA 接口规范，使用两阶段提交来完成一个全局事务，XA规范的基础是两阶段提交协议。 在第一阶段，交易中间件请求所有相关数据库准备提交（预提交）各自的事务分支，以确认是否所有相关数据库都可以提交各自的事务分支。当某一数据库收到预提交后，如果可以提交属于自己的事务分支，则将自己在该事务分支中所做的操作固定记录下来，并给交易中间件一个同意提交的应答，此时数据库将不能再在该事务分支中加入任何操作，但此时数据库并没有真正提交该事务，数据库对共享资源的操作还未释放（处于上锁状态）。如果由于某种原因数据库无法提交属于自己的事务分支，它将回滚自己的所有操作，释放对共享资源上的锁，并返回给交易中间件失败应答。 在第二阶段，交易中间件审查所有数据库返回的预提交结果，如所有数据库都可以提交，交易中间件将要求所有数据库做正式提交，这样该全局事务被提交。而如果有任一数据库预提交返回失败，交易中间件将要求所有其它数据库回滚其操作，这样该全局事务被回滚。 以一个全局事务为例，AP首先通知交易中间件开始一个全局事务，交易中间件通过XA接口函数通知数据库开始事务，然后AP可以对数据库管理的资源进行操作，数据库系统记录事务对本地资源的所有操作。操作完成后交易中间件通过XA接口函数通知数据库操作完成。交易中间件负责记录AP操作过哪些数据库（事务分支）。AP根据情况通知交易中间件提交该全局事务，交易中间件会通过XA接口函数要求各个数据库做预提交，所有数据库返回成功后要求各个数据库做正式提交，此时一笔全局事务结束。XA规范对应用来说，最大好处在于事务的完整性由交易中间件和数据库通过XA接口控制，AP只需要关注与数据库的应用逻辑的处理，而无需过多关心事务的完整性，应用设计开发会简化很多。具体来说，如果没有交易中间件，应用系统需要在程序内部直接通知数据库开始、结束和提交事务，当出现异常情况时必须由专门的程序对数据库进行反向操作才能完成回滚。如果是有很多事务分支的全局事务，回滚时情况将变得异常复杂。而使用XA接口，则全局事务的提交是由交易中间件控制，应用程序只需通知交易中间件提交或回滚事务，就可以控制整个事务（可能涉及多个异地的数据库）的全部提交或回滚。 |
Jboss就好似这种XA中间件，用户只要在代码中显示的利用JTA接口开启、提交事务，调用预先配置好的XA数据源就可以了，底层如何做的对用户是透明的。Jboss为你做了这一切，尽管全局性事务执行速度上有些慢……
2. 事务的传播与隔离
事务具有隔离性，并发程序发生的时候，一般有以下5种策略：
1.没有任何隔离限制
| connection1.setTransactionIsolation(Connection.TRANSACTION_NONE); |
2.可以读取未提交事务的数据，对方已经触发了相关业务（取了50块钱），但是食物还没提交到数据库中呢，您这边读到的数据已经是少了50块的数据。
| connection1.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED); |
3.获取的永远是提交后的值，这种保证独到的都是数据库的新值。也值通常采用的策略。
| connection1.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED); |
4.相对于第三种情况对于单表基本上可以满足事务需求，但是会导致读取2次，结果不相同的事情发生。单表中可以用下面策略解决
| connection1.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ); |
5.真正的可串行化的失误，不过效率最低，资源占用最多。
| connection1.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE); |
3. 事务的传播性
如果已经包含在一个事务中的程序想访问其他程序，那么此事务会不会影响另一段程序呢，就要看您的传播策略了
有6种策略
1.Required：共享型
若1处在一个事务中调用了2，则2直接和1在同一个事务中。若1没有任何事务，则系统会默认给2创建一个新事务。此策略适合大多数情况。
2.RequiredNew：独立型
若1在一个事务中调用了2，则系统先将1的事务挂起，不管、之后为2设置一个新事务，执行完毕后恢复1的事务。若1没有事务，则会为2新开一个事务。
3.Mandatory：强制共享型
若1处在一个事务中调用了2，则2直接和1在同一个事务中。若1没有任何事务，直接抛出异常——Transaction RequiredException。
4.NotSupported：无助独立型
若1在一个事务中调用了2，则系统先将1的事务挂起，不管、之后2不开启任何事务，执行完毕后恢复1的事务。若1没有事务，2也直接执行。
5. Supported：啃老型
若1处在一个事务中调用了2，则2直接和1在同一个事务中。若1没有任何事务，直接执行2。
6.Never：捣乱型
若1处在一个事务中调用了2，则抛出RemoteException。若1没有任何事务，直接执行2也不会为它开启任何事务。
4. EJB的事务管理
EJB使用2种方式管理事务：
1. CMT：容器管理——依靠应用服务器，声明式管理
2. BMT：Bean自行管理——代码自己显示管理
之后单独做笔记SessionBean时再详细讨论
5. 事务超时
容器管理方式的可以通过容器进行配置，硬编码的可以通过显示代码注明。
| userTransaction.setTransactionTimeout(20) |