关于事务的一点浅显简单理解

关于事务的一点浅显简单理解

我只从四个性质上发表一些简单看法:
原子性:事务是最小的执行单位,不允许分割。数据库事务可以包含一个或多个数据库操作,可以是一条或者多条sql语句,这些操作命令构成一个逻辑上的整体。构成逻辑整体的这些数据库操作, 要么全部执行成功,要么全部不执行。我们一般会把@Tracsation标注在Service方法层,一个Service方法可能包含对多个数据库增删改查的的操作,那我理解这样一个Service方法是一个逻辑整体,是一个事务。或者说一次性执行多条sql命令语句,这些sql语句构成一个整体,要么全部成功,要么全部不执行,构成了一个事务。

持久性:一个事务被提交之后。它对数据库中数据的改变是永久性的,即使数据库发生故障也不应该对其有任何影响。

隔离性:并发访问数据库时资源的时候,各并发事务之间相互影响的程度。事务的隔离性可以分为4种类型的隔离级别:Read Uncommitted,Read Committed, Repeatable Read和Serilization,这是种隔离级别在并发访问的时候可能出现的问题有:
1.脏写:事务回滚了其他事务对数据项的已提交结果
  比如下面这种情况:有事务1和事务2,事务2对数据A做了修改并且提交,但事务1对数据A回滚,导致事务2对数据A的已提交修改也被回滚了。
2.丢失更新:事务覆盖了其他事务对数据的已提交修改,导致这些修改好像丢失了一样
  比如下面这种情况:有事务1和事务2,事务1和事务2读取数据A的值都为10,事务2先将数据A加上10并提交修改,之后事务1将数据A减少10并提交修改,A的值最后为10,导致事务2对A的修改好像丢失了一样
3.脏读:一个事务读取了另一个事务未提交的数据
  比如下面这种情况:有事务1和事务2,在事务1对数据A的处理过程中(如将数据A的值由10改为了20,但尚未提交修改),事务2读取了数据A的值,但之后事务1回滚了,导致事务2读取的数据A是未提交的脏数据
4.不可重复读:一个事务对同一数据的读取结果前后不一致
  比如下面这种情况:有事务1和事务2,事务1读取数据A,之后事务2对数据A进行了修改并提交,事务1再次读取读取数据A结果不一样了。
  脏读和不可重复读的区别:前者读取的是事务未提交的脏数据,后者读取的是事务已经提交的数据,只不过因为数据被其他事务修改过导致前后两次读取的结果不一样。
5.幻读:事务读取某个范围的数据时,因为其他事务的操作导致前后两次读取的结果不一致
幻读和不可重复读的区别:不可重复读是针对确定的某一行数据而言,而幻读是针对不确定的多行数据。因而幻读通常出现在_带有查询条件的范围查询中。

常见的并发控制技术有:基于封锁、基于时间戳、基于有效性检查、基于快照隔离

一致性:事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态—看似套娃说法,用一致性解释一致性,其实还是有一定道理的。

我认为事务的一致性靠两方面来保证,一个是数据库本身,一个是程序员写的代码。
在数据库中,我们可以为每张表建立主键、唯一索引、外键、声明某列数据非空来对事务进行约束。这样的约束可以保证表格数据符合现实逻辑。其次,我们程序员写代码的时候,也要负责做到事务的一致性。由于数据库中的数据是一个整体,是相互关联的,例如某个数据的增减会影响到另一行数据或者另一张表的数据的减增,这需要我们程序员自己用代码实现,从而保证在执行事务前后数据库的整体的关联性不会遭到破坏,我的理解是数据库在操作前后关联性一致。

最后,还有一个认知上的问题,就说之前认为只要在类上标注了@TracSation那就算一个事务,它就有了四种性质,其实不是的,而是满足了这四种性质才能称为事务,否则就是一个假的事务。其中原子性、隔离性、永久性不太需要我们去关系,一致性才是决定我们能否写出一个真事务的关键。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值