如何用java开启mysql事务,要求详细

如何用java开启mysql事务,要求详细,第1张

看你是什么事务,jdbc事务,还是分布式事务,还是容器事务

1,编程式事务管理(jdbc的事务是绑定在connection上的)

Connection conn = null

try

{

Class.forName("com.mysql.jdbc.Driver")

conn = DriverManager.getConnection("jdbc:oracle:thin:@host:1521:SID","username","password")

conn.setAutoCommit(false) //取消自动提交

PreparedStatement ps = conn.prepareCall("update something")

ResultSet rs = ps.executeQuery()

conn.commit() //手动提交

}

catch (Exception e)

{

conn.rollback()

e.printStackTrace()

}

finally

{

conn.close()

}

2,声明式事务

先在工程的application.xml配置文件中添加如下代码,开启事务

<!-- 声明式事务控制配置 -->

<tx:annotation-driven transaction-manager="txManager"/>

<bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

<property name="datasource" ref="bassDataSource"></property>

</bean>

然后在你需要开启事务的接口前面添加注解

@Transactional(rollbackFor = IOException.class)

public void add(String name) throws IOException

{

System.out.println("可以再类里和方法里面添加事务注解0~0")

throw new IOException()

}

直接调用接口方法就好

分布式事务处理(mysql貌似在5.X之后才支持) 的话,

1.可以直接使用spring+atomikos框架进行管理

参考:

就不贴测试代码了,自己看着配置吧

2,使用JTA(Java Transaction API)进行分布式事务管理(测试代码如下)

import java.sql.Connection

import java.sql.PreparedStatement

import java.sql.SQLException

import javax.naming.InitialContext

import javax.sql.DataSource

import javax.transaction.SystemException

import javax.transaction.UserTransaction

import com.mysql.jdbc.jdbc2.optional.MysqlDataSource

//分布式事务处理

public class transferAccount

{

@SuppressWarnings("null")

public void testTransferAccount()

{

UserTransaction userts = null

Connection connA = null

PreparedStatement psA = null

InitialContext context = null

Connection connB = null

PreparedStatement psB = null

try

{

//获得事务管理对象

userts = (UserTransaction) context.lookup("java:comp/UserTransaction")

//获取两个数据

connA = getDataSourceA().getConnection()

connB = getDataSourceB().getConnection()

//开启事务

userts.begin()

//sql语句

psA = connA.prepareStatement("我加1")

psB = connB.prepareStatement("我减1")

//执行sql

psA.executeUpdate()

psB.executeUpdate()

//事务提交

userts.commit()

} catch (Exception e)

{

try

{

userts.rollback()

} catch (IllegalStateException | SecurityException

| SystemException e1)

{

e1.printStackTrace()

}

e.printStackTrace()

}

finally

{

try

{

psA.close()

psB.close()

connA.close()

connB.close()

} catch (SQLException e)

{

e.printStackTrace()

}

}

}

public DataSource getDataSourceA()

{

MysqlDataSource dataSource = new MysqlDataSource()

dataSource.setDatabaseName("mysql")

dataSource.setServerName("server")

dataSource.setPortNumber(1433)

dataSource.setUser("test")

dataSource.setPassword("test")

return dataSource

}

public DataSource getDataSourceB()

{

MysqlDataSource dataSource = new MysqlDataSource()

dataSource.setDatabaseName("mysql")

dataSource.setServerName("server")

dataSource.setPortNumber(1435)

dataSource.setUser("test1")

dataSource.setPassword("test1")

return dataSource

}

}

今天我们来看看多个事务对缓存页里的同一条数据同时进行更新或者查询,此时会产生哪些问题?这里实际会涉及到 脏写、脏读、不可重复读、幻读, 四中问题。

这个脏写的话,它的意思是说有两个事务,事务A和事务B同时在更新一条数据,事务A先把它更新为A值,事务B紧接着就把它更新为B值。事务A是先更新的,它在更新之前,这行数据的值为NULL,所以此时事务A的undo log日志大概是这样的:更新之前这行数据的值为NULL,主键为XX 。

那么此时事务B更新完了数据的值为B,结果此时事务A突然回滚了,那么就会用它的undo log日志去回滚。此时事务A一回滚,直接就会把那行数据的值更新回之前的NULL值。所以对于事务B看到的场景,就是自己明明更新了,结果值却没了,这就是 脏写。

假设事务A更新了一行数据的值为A,此时事务B去查询了一些这行数据的值,看到的值是A,然后事务B拿着刚查询到的A值去处理各种业务。但是此时不幸的事情发生了,事务A突然回滚了,导致它刚才更新的A值没了,此时那行数据的值回滚为NULL值。这就是所谓的 脏读。 它的本质是事务B去查询了事务A修改过的数据,但是此时事务A还没有提交,事务A随时会回滚导致事务B查询了一个不存在的值。

接着我们来看一下 的问题,假设我们有一个事务A开启了,在这个事务A里会多次对一条数据进行查询。然后另外有两个事务,一个是事务B,一个是事务C,它们都是对一条数据进行更新的。假设缓存页里一条数据原来的值是A值,此时事务A开启之后,第一次查询这条数据,读取到的是A值。接着事务B更新了那行数据的值为B,同时提交事务,然后事务A第二次查询该行数据,此时查到的是事务B修改过的值B 。接着事务C更新了那行数据的值为C,同时提交事务,然后事务A第三次查询该行数据,此时查到的是事务C修改过的值C值。

那么上面的场景有什么问题呢?其实要说没问题也是可以的,毕竟事务B和C都提交事务了。但是要说有问题也是可以的,就是事务A可能第一次查询到的是A值,那么它可能希望的是在事务执行期间,如果多次查询数据,都是同样的一个A值。但是该场景下,A值明显不是可重复读的。

这种情况算不算一个问题呢?其实这是根据你的业务决定的。有的业务要的是可重复读,而有的业务却需要不可重复读。

假设一个事务A先发送一条SQL语句,里面有一个条件,要查询一批数据出来,比如“select * from table where id >10”,类似这种SQL,它一开始查询出了10条数据。然后事务B往表里插入了几条数据,而且事务B还提交了。此时事务A再次查询,由于事务B插入了几条数据,导致这次它查询出来了12条数据。同样的SQL语句,两次的查询结果却不一样,所以开始怀疑自己是不是出现了幻觉?导致刚才幻读了?这就是幻读一词的由来。

在SQL标准中规定了4种事务隔离级别,就是说多个事务并发运行的时候,互相是如何隔离的,从而避免一些事务并发问题。这4种级别包括了: read uncommitted(读未提交)、read committed(读已提交)、repeatable read(可重复读)、serializable(串行化)

第一个read uncommitted隔离级别是不允许发生脏写的。也就是说,不可能两个事务在没提交的情况下去更新同一行数据的值,但是在这种隔离级别下,可能发生脏读、不可重复读、幻读。所以一般来说,是没有人做系统开发的时候把事务隔离级别设置为读未提交这个级别的。

第二个是read committed隔离级别,也就是俗称的RC级别,这个级别不会发生脏写和脏读。也就是说,别的事务没提交的情况下修改的值,你是绝对读不到的。但是,可能会发生不可重复读和幻读问题。

第三个是repeatable read隔离级别,也就是俗称的RR级别,就是可重复读级别。这个级别下,不会发生脏写、脏读、不可重复读的问题。事务一旦开启,多次查询一个值,会一直读到同一个值。但是它会发生幻读的问题。

最后一个隔离级别,就是serializable级别,这种级别,根本不允许多个事务并发执行,只能串行执行,所以不可能有幻读问题。但是这种级别一般除非脑子坏了,否则不可能设置这种级别。

MySQL默认设置的事务隔离级别都是RR级别的,而且MySQL的RR级别是可以避免幻读发生的。

下面的命令可以修改MySQL的默认事务隔离级别:

另外,给大家一个彩蛋,假设你在开发业务系统的时候,比如用spring里的@Transaction注解来做事务这块,假设某个事务你就是有点手痒,想搞成RC级别,那么没问题,在@Transaction注解里是有一个isolation参数的,里面是可以设置事务隔离级别的,具体的设置方式如下:

@Transaction(isolation=Isolation.DEFAULT),默认的就是DEFAULT值,这个就是MySQL默认支持什么隔离就是什么隔离级别。但是你可以手动改成其它的隔离级别,比如,isolation = Isolation.READ_COMMITTED级别,此时你就可以读取到其它事务已提交的数据。

简单来说,我们每条数据其实都有两个隐藏字段,一个是trx_id,一个是roll_pointer,这个trx_id就是最近一次更新这条数据的事务id,roll_pointer就是指向了你更新这个事务之前生成的undo log,关于undo log之前都讲过了。

举个例子,假设有一个事务A(id=50),插入了一条数据,那么此时这条数据的隐藏字段以及指向的undo log如下图所示:

插入的这条数据的值是A,因为事务A的id是50,所以这条数据的trx_id就是50,roll_pointer指向一个空的undo log,因为之前这条数据是没有的。接着有一个事务B修改了一下这条数据,把值改成了B,事务B的id是58,那么此时更新之前会生成一个undo log记录之前的值,然后会让roll_pointer指向这个实际的undo log回滚日志,如下图所示:

ACID 是为保证事务(transaction)是正确可靠的,所必须具备的四个特性:

以 A 给 B 转账100元为例:

MySQL事务是由 InnoDB 存储引擎实现的。

可以用如下的命令显式的开启事务:

另外,在自动提交(autocommit)模式下,我们执行的每一条 SQL 语句都是一条独立的事务;如果关闭了自动提交(autocommit)模式,则所有的 SQL 语句都在一个事务中,直到执行了 commit 或 rollback,该事务结束,同时开始了另外一个事务。

MySQL 事务的 ACID 特性靠如下机制实现:

Go 语言的 Gorm 提供了对于事务 *** 作的支持:

此外,还有嵌套事务以及手动事务等 *** 作,可以参考中文文档: learnku.com/docs/gorm/v…

@Transactional 注解必须添加在public方法上,private、protected方法上是无效的。

一般情况下,推荐将@Transactional 注解加在方法上,因为@Transactional直接加在类或者接口上,@Transactional注解会对类或者接口里面所有的public方法都有效,会影响性能。


欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/zaji/8641631.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-19
下一篇2023-04-19

发表评论

登录后才能评论

评论列表(0条)

    保存