建设一个聊天类的网站,深圳口碑好的vi设计公司,只用网站开发VS就安装那些就够了,个人建网站允许吗1 事务
1.1事务管理方式
spring支持编程式事务管理和声明式事务管理两种方式。
编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理#xff0c;spring推荐使用TransactionTemplate。
声明式事务管理建立在AOP之上的…1 事务
1.1事务管理方式
spring支持编程式事务管理和声明式事务管理两种方式。
编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理spring推荐使用TransactionTemplate。
声明式事务管理建立在AOP之上的。其本质是对方法前后进行拦截然后在目标方法开始之前创建或者加入一个事务在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务这样就不需要在业务逻辑代码中掺杂事务管理的代码只需在配置文件中做相关的事务规则声明(或通过基于Transactional注解的方式)便可以将事务规则应用到业务逻辑中。
显然声明式事务管理要优于编程式事务管理这正是spring倡导的非侵入式的开发方式。声明式事务管理使业务代码不受污染一个普通的POJO对象只要加上注解就可以获得完全的事务支持。和编程式事务相比声明式事务唯一不足地方是后者的最细粒度只能作用到方法级别无法做到像编程式事务那样可以作用到代码块级别。但是即便有这样的需求也存在很多变通的方法比如可以将需要进行事务管理的代码块独立为方法等等。
声明式事务管理也有两种常用的方式一种是基于tx和aop名字空间的xml配置文件另一种就是基于Transactional注解。显然基于注解的方式更简单易用更清爽。 1.2自动提交(AutoCommit)与连接关闭时的是否自动提交
默认情况下数据库处于自动提交模式。每一条语句处于一个单独的事务中在这条语句执行完毕时如果执行成功则隐式的提交事务如果执行失败则隐式的回滚事务。对于正常的事务管理是一组相关的操作处于一个事务之中因此必须关闭数据库的自动提交模式。不过spring会将底层连接的自动提交特性设置为false。
当一个连接关闭时如果有未提交的事务应该如何处理JDBC规范没有提及C3P0默认的策略是回滚任何未提交的事务。这是一个正确的策略但JDBC驱动提供商之间对此问题并没有达成一致。 1.3事务隔离级别
隔离级别是指若干个并发的事务之间的隔离程度。TransactionDefinition 接口中定义了五个表示隔离级别的常量
1、TransactionDefinition.ISOLATION_DEFAULT这是默认值表示使用底层数据库的默认隔离级别。对大部分数据库而言通常这值就是TransactionDefinition.ISOLATION_READ_COMMITTED
2、TransactionDefinition.ISOLATION_READ_UNCOMMITTED该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读不可重复读和幻读因此很少使用该隔离级别。比如PostgreSQL实际上并没有此级别。
3、TransactionDefinition.ISOLATION_READ_COMMITTED该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读这也是大多数情况下的推荐值。
4、TransactionDefinition.ISOLATION_REPEATABLE_READ该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询并且每次返回的记录都相同。该级别可以防止脏读和不可重复读。
5、TransactionDefinition.ISOLATION_SERIALIZABLE所有的事务依次逐个执行这样事务之间就完全不可能产生干扰也就是说该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。
注
MYSQL: 默认为REPEATABLE_READ级别 SQLSERVER: 默认为READ_COMMITTED
脏读 一个事务读取到另一事务未提交的更新数据 不可重复读 在同一事务中, 多次读取同一数据返回的结果有所不同, 换句话说, 后续读取可以读到另一事务已提交的更新数据. 相反, 可重复读在同一事务中多次 读取数据时, 能够保证所读数据一样, 也就是后续读取不能读到另一事务已提交的更新数据
幻读 一个事务读到另一个事务已提交的insert数据。 1.4事务传播行为
所谓事务的传播行为是指如果在开始当前事务之前一个事务上下文已经存在此时有若干选项可以指定一个事务性方法的执行行为。在TransactionDefinition定义中包括了如下几个表示传播行为的常量
1、TransactionDefinition.PROPAGATION_REQUIRED如果当前存在事务则加入该事务如果当前没有事务则创建一个新的事务。这是默认值。
2、TransactionDefinition.PROPAGATION_REQUIRES_NEW创建一个新的事务如果当前存在事务则把当前事务挂起。
3、TransactionDefinition.PROPAGATION_SUPPORTS如果当前存在事务则加入该事务如果当前没有事务则以非事务的方式继续运行。
4、TransactionDefinition.PROPAGATION_NOT_SUPPORTED以非事务方式运行如果当前存在事务则把当前事务挂起。
5、TransactionDefinition.PROPAGATION_NEVER以非事务方式运行如果当前存在事务则抛出异常。
6、TransactionDefinition.PROPAGATION_MANDATORY如果当前存在事务则加入该事务如果当前没有事务则抛出异常。
7、TransactionDefinition.PROPAGATION_NESTED如果当前存在事务则创建一个事务作为当前事务的嵌套事务来运行如果当前没有事务则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED 例如Transactional(propagationPropagation.REQUIRED) 1.5事务超时
所谓事务超时就是指一个事务所允许执行的最长时间如果超过该时间限制但事务还没有完成则自动回滚事务。在 TransactionDefinition 中以 int 的值来表示超时时间其单位是秒。
默认设置为底层事务系统的超时值如果底层数据库事务系统没有设置超时值那么就是none没有超时限制。Transactional(timeout30) //默认是30秒 1.6事务只读属性
只读事务用于客户代码只读但不修改数据的情形只读事务用于特定情景下的优化比如使用Hibernate的时候。默认为读写事务。
Transactional(propagationPropagation.NOT_SUPPORTED,readOnlytrue)
只读标志只在事务启动时应用否则即使配置也会被忽略。启动事务会增加线程开销数据库因共享读取而锁定(具体跟数据库类型和事务隔离级别有关)。通常情况下仅是读取数据时不必设置只读事务而增加额外的系统开销。 1.7 spring事务回滚规则
指示spring事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。spring事务管理器会捕捉任何未处理的异常然后依据规则决定是否回滚抛出异常的事务。
默认配置下spring只有在抛出的异常为运行时unchecked异常时才回滚该事务也就是抛出的异常为RuntimeException的子类(Errors也会导致事务回滚)而抛出checked异常编译器会检查到的异常叫受检查异常则不会导致事务回滚。 可以明确的配置在抛出那些异常时回滚事务包括checked异常。也可以明确定义那些异常抛出时不回滚事务。如 Transactional(notRollbackForRunTimeException.class)、Transactional(rollbackForException.class
还可以编程性的通过setRollbackOnly()方法来指示一个事务必须回滚在调用setRollbackOnly()后你所能执行的唯一操作就是回滚。 1.8 Transactional注解
Transactional 可以作用于接口、接口方法、类以及类方法上。当作用于类上时该类的所有 public 方法将都具有该类型的事务属性同时我们也可以在方法级别使用该标注来覆盖类级别的定义。
虽然 Transactional 注解可以作用于接口、接口方法、类以及类方法上但是 Spring 建议不要在接口或者接口方法上使用该注解因为这只有在使用基于接口的代理时它才会生效因为注解是不能继承的这就意味着如果你正在使用基于类的代理时那么事务的设置将不能被基于类的代理所识别而且对象也将不会被事务代理所包装将被确认为严重的。另外 Transactional 注解应该只被应用到 public 方法上这是由 Spring AOP 的本质决定的。如果你在 protected、private 或者默认可见性的方法上使用 Transactional 注解这将被忽略也不会抛出任何异常。
默认情况下只有来自外部的方法调用才会被AOP代理捕获也就是类内部方法调用本类内部的其他方法并不会引起事务行为即使被调用方法使用Transactional注解进行修饰。 2 关于UnexpectedRollbackException异常。 因为在被spring事务代理方法中 被代理的方法dosomething内部有异常抛出事务会标记为回滚并在最外层调用那service里的callB中回滚。 这种情况下transaction会正常的rollback。 这个时候我们再调用ServiceA的callB。程序会抛出org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only这样一个异常信息因为在ServiceA和ServiceB中的Transactional propagation都采用的默认值REQUREID。根据我们前面讲过的REQUIRED特性当ServiceA调用ServiceB的时候他们是处于同一个transaction中。当ServiceB中抛出了一个异常以后ServiceB会把当前的transaction标记为需要rollback设置rollBackOnly状态继续执行到serviceA 可是被erviceA中的方法捕获了并进行了处理也就不回滚了一直执行到最后commit。在commit时spring会判断回滚标志rollBackOnly状态若有回滚标记,回滚并抛出UnexpectedRollbackException异常因为出现了前后不一致。 此时程序可以正常的退出了也没有抛出UnexpectedRollbackException。原因是因为当ServiceA调用ServiceB时serviceB的doSomething是在一个新的transaction中执行的。当doSomething抛出异常以后仅仅是把新创建的transaction rollback了而不会影响到ServiceA的transaction。ServiceA就可以正常的进行commit。 3 访问多个数据源或者多个数据库
利用Transactional 的value属性定不同的事务管理器。主要用来满足在同一个系统中存在不同的事务管理器时可以用此参数来根据需要指定特定的transactionManager(配置文件中qualifier元素定义的名称)。比如在同一个系统中需要访问多个数据源或者多个数据库时则必然会配置多个事务管理器。
类或方法上添加注解Transactional(value system)或简写为Transactional(system)即显式的要求spring用idsystem的事务管理器来管理事务。该属性亦可省略省略的话用容器中缺省的事务管理器
注spring容器缺省事务管理器以加载顺序首先加载的作为缺省。例如如果
tx:annotation-driven transaction-managertransactionManagerX /tx:annotation-driven transaction-managertransactionManagerY /
定义在同一个文件中则第一个transactionManagerX作为缺省。定义在不同文件则按文件的加载顺序首先加载的作为缺省。 4 transaction和EntityManager
1、关于persistence context(持久化上下文)和database transaction事务
Transactional本身定义了单个事务的范围。这个事务在persistence context的范围内。JPA中的持久化上下文是EntityManager内部实现使用了Hibernate Session使用Hibernate作为持久化provider。持久化上下文仅仅是一个同步对象它记录了有限集合的Java对象的状态并且保证这些对象的变化最终持久化到数据库。这是与单个事务非常不同的概念。一个Entity Manager可以跨越多个事务使用而且的确是这样使用的。EntityManager何时跨越多个事务最常见的情况是应用使用Open Session In View模式处理懒初始化异常时。这种情况下视图层运行的多个查询处于独立的事务中而不是单事务的业务逻辑但这些查询由相同的entity manager管理。另一种情况是开发人员将持久化上下文标记为PersistenceContextType.EXTENDED这表示它能够响应多个请求。
如何定义EntityManager和Transaction之间的关系这由应用开发者来选择但是JPA Entity Manager最常用的方式是“Entity Manager per application transaction”(每个事务都有自己的实体管理器)模式。entity manager注入的常用方法是 PersistenceContext private EntityManager em; 这里默认为“Entity Manager per transaction”模式。这种模式下如果在Transactional方法内部使用该Entity Manager那么该方法将在单一事务中运行。EntityManager是一个接口注入到spring bean中的不是entity manager本身而是在运行时代理具体entity manager的context aware proxy上下文感知代理。
2、事务的实现
实现了EntityManager接口的持久化上下文代理并不是声明式事务管理的唯一部分事实上包含三个组成部分
EntityManager Proxy本身、事务的切面、事务管理器 这三部分以及它们之间的相互作用如下。
1、事务的切面
事务的切面是一个“around环绕”切面在注解的业务方法前后都可以被调用。实现切面的具体类是TransactionInterceptor。
事务的切面有两个主要职责
在’before’时切面提供一个调用点来决定被调用业务方法应该在正在进行事务的范围内运行还是开始一个新的独立事务。 在’after’时切面需要确定事务被提交回滚或者继续运行。 在’before’时事务切面自身不包含任何决策逻辑是否开始新事务的决策委派给事务管理器完成。
2、事务管理器
事务管理器需要解决下面两个问题
新的Entity Manager是否应该被创建是否应该开始新的事务这些需要事务切面’before’逻辑被调用时决定。事务管理器的决策基于以下两点
事务是否正在进行 事务方法的propagation属性比如REQUIRES_NEW总要开始新事务 如果事务管理器确定要创建新事务那么将创建一个新的entity managerentity manager绑定到当前线程从数据库连接池中获取连接将连接绑定到当前线程使用ThreadLocal变量将entity manager和数据库连接都绑定到当前线程。事务运行时他们存储在线程中当它们不再被使用时事务管理器决定是否将他们清除。程序的任何部分如果需要当前的entity manager和数据库连接都可以从线程中获取。
3、EntityManager proxy
当业务方法调用entityManager.persist()时这不是由entity manager直接调用的。而是业务方法调用代理代理从线程获取当前的entity manager事务管理器将entity manager绑定到线程。
