
一是:如果你用到开源框架hibernater的话,在hibernater里面它提供了事务工厂,你可以利用这个类来进行事务 *** 作。
二是:我们一般有Connection连接对象来对事务进行 *** 作。
每个使用关系型数据库的程序都可能遇到数据死锁或不可用的情况,而这些情况需要在代码中编程来解决本文主要介绍与数据库事务死锁等情况相关的重试逻辑概念,此外,还会探讨如何避免死锁等问题,文章以DB2(版本9)与为例进行讲解。
什么是数据库锁定与死锁锁定(Locking)发生在当一个事务获得对某一资源的“锁”时,这时,其他的事务就不能更改这个资源了,这种机制的存在是为了保证数据一致性在设计与数据库交互的程序时,必须处理锁与资源不可用的情况。
锁定是个比较复杂的概念,仔细说起来可能又需要一大篇,所以在本文中,只把锁定看作是一个临时事件,这意味着如果一个资源被锁定,它总会在以后某个时间被释放。
而死锁发生在当多个进程访问同一数据库时,其中每个进程拥有的锁都是其他进程所需的,由此造成每个进程都无法继续下去。
如何避免锁我们可利用事务型数据库中的隔离级别机制来避免锁的创建,正确地使用隔离级别可使程序处理更多的并发事件(如允许多个用户访问数据),还能预防像丢失修改(LostUpdate)、读“脏”数据(DirtyRead)、不可重复读(NonrepeatableRead)及“虚”(Phantom)等问题。
隔离级别问题现象丢失修改读“脏”数据不可重复读“虚”可重复读取NoNoNoNo读取稳定性NoNoNoYes光标稳定性NoNoYesYes未提交的读NoYesYesYes表1:DB2的隔离级别与其对应的问题现象在只读模式中,就可以防止锁定发生,而不用那些未提交只读隔离级别的含糊语句。
浙江电脑培训http://www.kmbdqn.cn/发现一条SQL语句当使用了下列命令之一时,就应该考虑只读模式了
Spring配置中transactionAttributes的使用方法和作用最近碰到这个问题,在使用spring提供的JpaTemplate进行查询时,如果数据量超过100 条,查询效率就会明显降低。由于开始时使用JPA内部的双向关联,造成各实体内部关联过多,从而影响所有的 *** 作,因此怀疑是因为JPA的关联关系所致。但 是去掉关联关系后的效果不显著。
查找spring的相关配置,发现原来关于“transactionAttributes”有问题。原来的配置如下:
<bean id="baseTransactionProxy" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
lazy-init="true" abstract="true">
<property name="transactionManager">
<ref bean="transactionManager" />
</property>
<property name="transactionAttributes">
<props>
<prop key="sav*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>
使用上述配置,在JPA打出的日志中显示每次查询时都要进行更新 *** 作,查阅相关spring 的资料后发现transactionAttributes的各种属性的意义,现把资料分享如下:
PROPAGATION_REQUIRED--支持当前事务,如果当前没有事务,就新建一个事务。这是最常见的选择。
PROPAGATION_SUPPORTS--支持当前事务,如果当前没有事务,就以非事务方式执行。
PROPAGATION_MANDATORY--支持当前事务,如果当前没有事务,就抛出异常。
PROPAGATION_REQUIRES_NEW--新建事务,如果当前存在事务,把当前事务挂起。
PROPAGATION_NOT_SUPPORTED--以非事务方式执行 *** 作,如果当前存在事务,就把当前事务挂起。
PROPAGATION_NEVER--以非事务方式执行,如果当前存在事务,则抛出异常。
PROPAGATION_NESTED--如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则进行与PROPAGATION_REQUIRED类似的 *** 作。
当前所有的事务都使用“PROPAGATION_REQUIRED”属性值,并且控制事务的 *** 作权限为只读,以保证查询时不会更新数据。根据上述 定义 “PROPAGATION_REQUIRED”属性会造成为所有的 *** 作都创建事务,从而会出现JPA的日志中查询时也会进行更新 *** 作的现象,也就造成了效 率的低下。将所有查询的 *** 作改成事务类型为“PROPAGATION_NEVER”(不使用事务),则查询效率立即提升,但是此时担心一个问题:比如在一 个saveXXX()的方法中,如果方法内部使用更新、查询、再更新的 *** 作流程,会不会造成调用查询时,由于上述配置造成的抛出异常。
另外,如果出现
〈prop key="myMethod"〉PROPAGATION_REQUIRED,readOnly,-Exception〈/prop〉
这样的配置,其中:
-Exception表示有Exception抛出时,事务回滚. -代表回滚+就代表提交
readonly 就是read only, 设置 *** 作权限为只读,一般用于查询的方法,优化作用.
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)