JTA笔记

来源:互联网 发布:php什么时候用抽象类 编辑:程序博客网 时间:2024/05/03 12:55


1、事务基本属性
原子性:或者全部成功,或者全部失败;
一致性:遵守环境约束,如外键约束;
隔离性:事务间相互隔离,在提交之前看不到对方数据作出修改;
持久性:固化到数据库;


2、事务传播属性
当包含在事务中的两个方法互相调用时,传播属性决定如何使用事务;
传播属性定义在服务端(被调用方),由客户端和服务端的事务上下文共同决定事务运作方式;

Required PROPAGATION_REQUIRED
如果客户端已经包含在事务上下文中,则服务端加入客户端事务;如果客户端没有事务上下文,则容器为服务端新启一个事务;

RequiresNew PROPAGATION_REQUIRES_NEW
如果客户端包含在事务上下文中,则容器采取如下步骤:
1、挂起客户端事务;2、启动一个新事务;3、在新事务中完成服务端调用;4、重启客户端事务;
如果客户端没有包含事务上下文,容器为服务端新启动一个事务;

Mandatory
如果客户端已经包含在事务上下文中,则服务端加入客户端事务;如果客户端没有事务上下文,则容器抛出异常;

NotSupported
如果客户端已经包含在事务上下文中,则容器挂起客户端事务,服务端不运行在事务上下文中,调用结束后容器重启客户端事务;

Supports
如果客户端已经包含在事务上下文中,则服务端加入客户端事务;如果客户端没有事务上下文,服务端不运行在事务上下文中;

Never
如果客户端已经包含在事务上下文中,则容器抛出异常RemoteException;服务端不启动事务;

PROPAGATION_NESTED
JDBC的SavePoint在应用层的体现,可以对某一部分操作单独commit/rollback




3、事务隔离级别
事务的隔离级别是指并发的事务之间对同一数据进行读取或者修改时在多大程度上可以看到对方的结果。
EJB和Spring都可以设置隔离的等级,但是这种设置严重依赖于底层数据库的支持;

TransactionReadUncommitted
事务间可以访问对方已修改但未提交的数据;

TransactinoReadCommited
事务间智能访问对方已经提交的数据;

TransactinoRepeatableRead
保证同一个事务中读取的数据总是相同的,即本事务提交之前看不到其他事务对数据作的修改,即使其他事务已经提交;

TransactionSerializable
对同一数据的修改只能顺序进行;


4、java Transaction API(JTA)
JTA是javaEE提供的管理分布式事务的一系列接口,它提供了TransactionManager和ResourceManager之间的沟通机制;


5、java Transaction Service(JTS)
JTS是和CORBA OTS规范对等的,它通常都是和应用服务器相关的,它支持了JTA所需要的功能。JTS支持内嵌事务,然而javaEE的具体实现却不支持;


6、javax.transaction.UserTransaction
提供给应用程序代码直接使用的接口,用于定义事务边界和获取事务状态;


7、javax.transaction.TransactionManager
主要由应用服务器使用的接口,除了定义事务边界和获取事务状态,还可以挂起(suspend)或者重启(resume)事务;


8、javax.ejb.EJBContext
在EJB内部使用,主要使用setRollbackOnly()方法标记事务回滚,也可以用于获取UserTransaction;


9、UserTransaction方法总结
void begin()、int getStatus()、void commit()、void rollback()、void setRollbackOnly()、void setTransactionTimeout(int seconds);


10、TransactionMnanger方法总结
Transaction suspend()、void resume(Transaction tobj)、UserTransaction getUserTransaction()、void setRollbackOnly();


11、javax.transaction.Status
STATUS_ACTIVE、STATUS_MARKED_ROLLBACK、STATUS_NO_TRANSACTION、STATUS_PREPARED、STATUS_COMMITTED、STATUS_ROLLEDBACK、
STATUS_UNKNOWN、STATUS_PREPARING、STATUS_COMMITTING、STATUS_ROLLING_BACK


12、事务模型:类型
本地事务模型:Local Transaction Model
通过资源管理器管理事务,没有框架的控制,本质上是在连接层面控制事务边界,
1、直接通过JDBC连接控制DBMS的事务;
2、直接通过JMS Factory控制事务;


适用场景
数据修改逻辑简单;单个数据源;缺乏容器支持;
局限性
如果连接管理不善,容易造成连接泄露;
无法支持多数据源和分布式事务;
如果发现使用过程中有在不同方法之间将“物理连接”作为参数传递的冲动,那么说明“本地事务模型”已经不再适用了;


程序定制事务模型:Programmatic Transaction Model
利用java Transaction API(JTA)提供的接口,以及其实现java Transaction Service(JTS)提供的服务,通过程序代码来控制事务边界。
1、程序通过JNDI获取UserTransaction,调用begin/commit/rollback方法定义事务边界;
2、ejb通过ejb-jar.xml指定BMT事务,利用UserTransaction的begin/commit/rollback方法定义事务边界;

适用场景
由客户端发起的事务
事务边界内,部分代码不能进行事务控制,比如由于性能上的考虑;
局限性
无法利用事务传播属性,即事务上下文是独立的;复杂,不建议使用;


申明式事务模型
由容器控制事务的begin/commit/rollback,开发人员通过申明的方式告诉容器事务的范围和回滚条件,
1、ejb的CMT事务,通过ejb-jar.xml进行描述;
2、Spring事务,通过AOP进行描述;


本地事务
connection.setAutoCommit(false);
connection.commit();
connection.rollback();


程序定制事务模型
UserTransaction txn = sessionContext.getUserTransaction();
txn.begin();
txn.commit();
txn.rollback();


事务设计模式
客户端主导事务模式
由客户端发起的事务,当客户端需要访问多个远程接口,这些接口可能位于不同的domain中时使用;

适用场景
1、一个业务请求需要调用本地或远程的多个接口才能满足;
2、本地或远程业务接口本身粒度良好,但没有为当前业务请求专门的整合接口;
3、无法对本地或远程接口进行重构;
4、事务的ACID属性必需保证;
解决方案
客户端和远程服务器之间使用支持事务传播的协议进行通讯,如RMI;
服务端防范必需配置Mandatory事务属性;
服务端资源管理器不能有事务逻辑;


服务端主导事务模式
由服务端接口控制事务,对客户透明,当业务接口具有良好的粒度,可以通过一次接口调用完成业务逻辑时使用;

适用场景
客户端请求通常需要调用一次接口就可以完成;
服务端接口内部通过调用其他细粒度的接口来实现复杂业务逻辑;
解决方案
客户端不包含任何事务逻辑;
对于非运行时异常,服务端方法捕获后需要显式调用setRollbackOnly();
资源管理器不能存在事务逻辑;
服务端采用申明式事务模型,对insert、update采用required事务属性,对读取采用supports事务属性;

服务端代理事务模式
由服务端控制,代理给公共事务模块,结合“命令模式”来控制业务请求可以封装为命令;

适用场景
客户端请求可以采用“命令模式”;
客户端总是只需要发送一个请求给服务端就可以完成业务逻辑;
服务端入口唯一;
服务端的实现基于POJO;
解决方案
客户端不包含任何事务逻辑;
资源管理器不存在事务逻辑;
服务端尽在命令处理器中控制事务;
服务端方法捕获业务异常后需要调用setRollbackOnly();
服务端采用申明式事务模型,对insert、update采用required事务属性,对读取采用supports事务属性;
0 0
原创粉丝点击