事务

目录 查漏补缺笔记2019/05/19 文件格式后缀 丢失修改，脏读，不可重复读 超键，候选键，主键 构S(Stmcture)/完整性I(Integrity)/数据操纵M(Malippulation) 关系范式 系统设计 数据库语言 两段协议 SQL联表查询，函数substr，right 查漏补缺笔记2019/05/19 文件格式后缀 数据库文件的扩展名为.DBC 数据表文件的扩展名为 .DBF 表单文件的扩展名为 .SCX 项目文件的扩展名为 .PJX 丢失修改，脏读，不可重复读 事务之间的对数据的并发操作会带来三种问题：丢失修改，脏读，不可重复读。 丢失修改：一个事务读取一个数据时，另外一个事务也访问该同一数据。那么，在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。 脏读：当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据，根据脏数据的操作可能是不正确的。 不可重复读：一个事务内多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，这就发生了在一个事务内两次读到的数据是不一样的情况

大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 30 天，也是我第 30 次进行打卡这种操作。 今天我温习了该专栏里一篇叫《性能设计篇之“异步处理”》的文章。 关键词总结：异步处理设计（异步任务处理、前台系统、任务处理系统、Push 推模型、Pull 拉模型、Pull 的好处、推拉结合）、事件溯源（解决的问题、事件回放、事件重播、事件可变性、事件记录、结合异步处理）、异步处理分布式事务（一致性、交易凭证、注意点）、异步处理设计要点（故障导致的问题、幂等性支持、整体业务事务问题、是否适合异步处理、任务积压情况、异步处理本质）。 所学总结： 异步处理设计 异步任务处理 异步任务的处理方式。 前台系统 用于记录用户的请求，收到请求后给客户端让其知道，并让其等待至处理完毕。而我们在数据库或存储的操作上是以追加的形式，所以性能会比较的高。 任务处理系统 我们需要将任务解耦，可以借助两个模型：Push 推模型和 Pull 拉模型。 Push 推模型 将任务分发给相应的服务去处理。可以起到调用的作用，但是需要知道下游服务的工作情况。 Pull 拉模型 由处理的服务来拉取要处理的任务。 Pull 的好处 上游服务无需关心下游服务的工作状态。 推拉结合 Push 做任务调度，类似于物流将相同商品的订单合并起来打包交给下游服务让其一次处理完毕

对于支持Transaction的数据库而言，必须有以下特征 一、Atomicity 原子性 一个事务中的所有操作，执行情况有两种：全部完成和全部不完成。不能停滞在中间某个环节，执行过程中出现错误时，会回滚到事务开始前的状态 二、Consistency 一致性 （wikipedia）:Ensures that any transaction will bring the database from one valid state to another. 定义的规则：constraints(约束)，cascades(级联),triggers(触发) 所有写入数据库的数据必须满足上述规则或者规则组合（Any data written to the database must be valid according to all defined rules） 不保证应用程序需求的事务正确性，仅仅保证任何程序错误不会导致破坏规则。 （百科）：一个事务可以封装状态改变（除非它是一个只读的）。事务必须始终保持系统处于一致的状态，不管在任何给定的时间并发事务有多少。 三、Isolation 隔离性（串行化） 提供隔离性是并发控制的主要目标。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。 四、Durability 持久性 事务完成后

发现 我们平时使用 分布式锁的方式有问题 如: try {} finnally{ 释放锁} ， 如果方法有事务的话 , 进到finnally 的时候并不代表，数据已经持久化。 会导致锁提前释放,正确的做法应该是 事物完成后再释放锁。 /** * 事务结束后释放锁 */ private void unlockAfterTransaction(LockResult lockResult) { //事物完成后释放锁 TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() { @Override public void afterCompletion(int status) { super.afterCompletion(status); distLockSservice.unlock(lockResult); } }); } 来源： CSDN 作者： 矫首遐观 链接： https://blog.csdn.net/u010408502/article/details/104001087

什么是事务： 数据库是所有系统的核心模块，它存储在磁盘中，在逻辑上，以数据的形式呈现给用户，支持增删改查（CRUD）并在过程中保证数据的正确，可靠。而做到这一点的，就是事务(Transaction)。 事务的四个特性（ACID）： 1.原子性（Atomicity）： 要么全部完成，要么全部取消 ，当对数据库进行操作时，根据业务逻辑，我们会操作个表中的数据，当一步操作出错时，会让该事务中的所有操作都回滚，数据还是未操作时的样子。 举例 ： 当A向B转账时，具体操作为：A账户减少100元，B账户上增加100元，但是此时B账户添加的时候出错了，导致A账户的钱没了，B转账未成功，或者是A的资金没有减少，但是B却平白无故增加了100元，所以A,B的账户的金额要么都成功，要么都失败。 2.隔离性（Isolation）： 有多个事务同时进行，最后结束时，最终的结果应该是相同的 举例 ：A向B转账100元，同时C又给A转账300元，最后的结果是A账户上增加了200元。而不是A增加了300，B增加了100，C少了300。 3.持久性（Durability）： 当事务结束时，数据会永久的保存到数据库里 举例 ：当A刚刚往外转完账时，数据库发生崩溃，但是转完账依旧会保存到数据库里。 4.一致性（Consistency）： 保证账户的数据不会凭空消失或产生，该特性依赖原子性，隔离性 世界上有10种人

消息队列（Message Queue），简称MQ，本质是一个队列，用于存放数据（message），先入先出（FIFO）。主要用于系统解耦、消息缓存。 目前市面上消息队列的实现有很多种，下面调研了kafka/rabbitMQ/rocketMQ，这三种应用都非常广泛，期望从中选出最合适我们的。 简介 Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache定级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。 RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。 RocketMQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理

SQL Server通过在锁资源上使用不同类型的锁来隔离事务。为了开发安全的事务，定义事务内容以及应在何种情况下回滚至关重要，定义如何以及在多长时间内在事务中保持锁定也同等重要。这由隔离级别决定。应用不同的隔离级别，SQL Server赋予开发者一种能力，让他们为每一个单独事务定义与其他事务的隔离程度。事务隔离级别的定义如下： · 是否在读数据的时候使用锁 · 读锁持续多长时间 · 在读数据的时候使用何种类型的锁 · 读操作希望读已经被其他事务排他锁住的数据时，怎么办？在这种情况下， SQL Server 可以： · 一直等到其他事务释放锁 · 读没有提交的数据 · 读数据最后提交后的版本 ANSI 99定义了4种事务隔离级别，SQL Server 2005能够完全支持这些级别： · 未提交读 在读数据时不会检查或使用任何锁。因此，在这种隔离级别中可能读取到没有提交的数据。 · 已提交读 只读取提交的数据并等待其他事务释放排他锁。读数据的共享锁在读操作完成后立即释放。已提交读是 SQL Server 的 默认 隔离级别。 · 可重复读 像已提交读级别那样读数据，但会保持共享锁直到事务结束。 · 可序列化 工作方式类似于可重复读。但它不仅会锁定受影响的数据，还会锁定这个范围。这就阻止了新数据插入查询所涉及的范围，这种情况可以导致幻像读。 此外，SQL

今天继续在讲解SOA技术实现方面的课程，这一周主要讨论的是WCF。既然讲到WCF，难免要提一下在其之前的有关技术。其中COM+我认为是非常值得回顾的。 COM+技术所能提供的功能 1、事务服务：它确保了在分布式系统中的数据完整性。 2、安全服务：它的安全模型提供了处理安全性而不用编写任何代码的方法。 3、同步服务：提供了有效管理地解决组件中并发问题的方法，但却不用编写代码。 4、资源管理：（包括资源管理器和资源分配器）管理数据库连接、网络连接和内存等。 5、JIT激活：即（Just In Time）是从MTS继承下来的一项服务，当客户调用时才将该对象的一个实例保持为活跃状态并缓存在服务器内存中，使用完对象后，会通知MTS环境可以释放该对象所占用的资源了，如数据库连接。 6、对象池：提供一个线程池来存放现成的对象，以供下次再用，是系统的一项自动服务。当有应用程序访问COM+组件时，即为应用程序创建该组件的一个实例并存放在对象池中，应用程序关闭后即销毁实例，可以自由配置组件使它的实例在池中的状态，实现了实例的重用性，提高应用程序的性能和伸缩性。 7、基于角色的安全：这个容易理解，即验证角色，给予安全许可，给不同的用户予不同的权限。 8、队列组件（MSMQ）：提供异步消息队列，可以自动按其形式将数据转换成数据包。 9、共享属性管理器（SPM）：用来管理存储在内存中的对象状态信息

使用Spring声明式事务方式控制事务简单方便（详解参考：链接: Spring事务@Transactional的说明和使用举例 .），但是有些场景还需要结合编程式事务方式使用。 如以下场景：添加@Transactional注解控制的方法有返回值，若此方法运行期间出现异常既需要回滚当前方法的事务，也要正常return返回值给调用此方法的上级使用。这时就需要手动回滚事务了。 import org . springframework . transaction . annotation . Transactional ; import org . springframework . transaction . interceptor . TransactionAspectSupport ; @Transactional ( rollbackFor = Exception . class ) @Override public List < String > testMethod ( ) { List < String > res = null ; try { // do something... res . add ( "message" ) ; if ( res . size ( ) < 0 ) { // 手动抛异常测试 throw new RuntimeException (

更多内容关注公众号：SAP Technical 各位可以关注我的公众号：SAP Technical SAP查看事务代码下的角色和用户 查看角色：SUIM——>Roles——>By Transaction Assignment 输入Transaction code即可看到事务代码下的角色。 查看用户：SUIM——> User——>By Transaction Authorization 输入Transaction code即可看到事务代码下的用户。 来源： CSDN 作者： SAPmatinal 链接： https://blog.csdn.net/SAPmatinal/article/details/103990685