事务

java的大方向就是JavaEE，JavaEE不仅仅是socket编程，具体包括13中核心技术。 　　JAVAEE的核心API与组件 　　JAVAEE平台由一整套服务（Services）、应用程序接口（APIs）和协议构成，它对开发基于Web的多层应用提供了功能支持，下面对JAVAEE中的13种技术规范进行简单的描述(限于篇幅，这里只进行简单的描述)： 　　1、JDBC(Java Database Connectivity) 　　JDBC API为访问不同的数据库提供了一种统一的途径，象ODBC一样，JDBC对开发者屏蔽了一些细节问题，另外，JDCB对数据库的访问也具有平台无关性。 　　2、JNDI(Java Name and Directory Interface) 　　JNDI API被用于执行名字和目录服务。它提供了一致的模型来存取和操作企业级的资源如DNS和LDAP，本地文件系统，或应用服务器中的对象。 　　3、EJB(Enterprise JavaBean) 　　JAVAEE技术之所以赢得媒体广泛重视的原因之一就是EJB。它们提供了一个框架来开发和实施分布式商务逻辑，由此很显著地简化了具有可伸缩性和高度复杂的企业级应用的开发。EJB规范定义了EJB组件在何时如何与它们的容器进行交互作用。容器负责提供公用的服务，例如目录服务、事务管理、安全性、资源缓冲池以及容错性

引言：SQL Server的事务日志传送备份是仅次于镜像的高可靠性备份方案，可以达到分钟级的灾难恢复能力。其项目实施成本，又远小于镜像的投入，因此是一种非常实用的备份解决方案。本文详细讲解了事务日志传送备份的实施过程。 一：系统要求 数据库服务器，名称Server-DW，Windows Server 2003 X64，安装SQL Server 2008，需要备份的数据库为"JKL_DW"。 备份服务器，名称Server-ETL，Windows Server 2003 X32，安装SQL Server 2008。 二：准备工作 1、在Server-ETL上创建文件夹，用于存放备份数据库，此例中命名为"jklDW"。 2、在Server-ETL上创建文件夹，用于存放为备份数据传送过来的事务日志。此例中命名为"LogBackup"，然后共享此文件夹，共享名称为"Server-ETL\LogBackup$"。 3、在Server-ETL上创建文件夹，用于存放为还原数据库复制的事务日志。此例中命名为"LogCopy"，然后共享此文件夹，共享名称为"Server-ETL\LogCopy$"。 4、为数据库"JKL_DW"创建一个完整备份。 （1）备份数据库 ─ 常规页 在“目标”处选择将数据库备份文件的路径。 （2）备份数据库 ─ 选项页 覆盖媒体： 改为"备份到新媒体集并清除所有现有备份集"

mysql锁机制分为表级锁和行级锁，本文就和大家分享一下我对mysql中行级锁中的共享锁与排他锁进行分享交流。 共享锁又称为读锁，简称S锁，顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。 排他锁又称为写锁，简称X锁，顾名思义，排他锁就是不能与其他所并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。 对于共享锁大家可能很好理解，就是多个事务只能读数据不能改数据，对于排他锁大家的理解可能就有些差别，我当初就犯了一个错误，以为排他锁锁住一行数据后，其他事务就不能读取和修改该行数据，其实不是这样的。排他锁指的是一个事务在一行数据加上排他锁后，其他事务不能再在其上加其他的锁。mysql InnoDB引擎默认的修改数据语句，update,delete,insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型，如果加排他锁可以使用select ...for update语句，加共享锁可以使用select ... lock in share mode语句。所以加过排他锁的数据行在其他事务种是不能修改数据的，也不能通过for update和lock in share mode锁的方式查询数据，但可以直接通过select ...from.

原子性：事务是一组不可分割的操作单元，这组单元要么同时成功要么同时失败（由DBMS的事务管理子系统来实现）； 一致性：事务前后的数据完整性要保持一致（由DBMS的完整性子系统执行测试任务）； 隔离性:多个用户的事务之间不要相互影响，要相互隔离（由DBMS的并发控制子系统实现）； 持久性:一个事务一旦提交，那么它对数据库产生的影响就是永久的不可逆的，如果后面再回滚或者出异常，都不会影响已提交的事务（由DBMS的恢复管理子系统实现的） 。。。 后续补充 来源： CSDN 作者： m.berg 链接： https://blog.csdn.net/Sampson_Hugo/article/details/104540740

事务的四大特性 1.原子性（Atomicity） 要么全做，要么全不做的规则称之为原子性。比如说转账,要么成功要么失败. 2.一致性（Consistency） 如果数据库中的数据全部符合现实世界中的约束（all defined rules），我们说这些数据就是一致的，或者说符合一致性的。比如身份证号不能重复 更多的一致性需求需要靠写业务代码的程序员自己保证。比如说金额不能小于0 , 性别只能是男或女. 3.隔离性（Isolation） 对某些数据库操作来说，不仅要保证这些操作以原子性的方式执行完成，而且要保证其它的状态转换不会影响到本次状态转换，这个规则被称之为隔离性。 4.持久性（Durability） 转换的结果将永久的保留，这个规则被称为持久性. 也就意味味着该转换对应的数据库操作所修改的数据都应该在磁盘上保留下来 MySQL中事务的语法 只有InnoDB和NDB存储引擎支持事务.如果表不支持事务,那么将无法回滚. 不显式的开启事务,那么每一条sql都是一个独立的事务 开启一个事务 BEGIN; START TRANSACTION; START TRANSACTION语句后边跟随几个修饰符，就是它们几个： READ WRITE：标识当前事务是一个只读事务 READ WRITE：标识当前事务是一个读写事务 WITH CONSISTENT SNAPSHOT：启动一致性读 提交事务

近日，在ArchSummit全球架构师峰会上，腾讯计费团队分享了在金融级核心交易解决方案TDMesh上的深度实践。这也是腾讯计费继今年5 月在腾讯全球数字生态大会首次线下展示后的又一大动作。   据了解，腾讯计费是孵化于支撑腾讯内部业务千亿级营收的互联网交易平台，它汇集了国内外主流支付渠道，提供账户管理、精准营销、安全风控、稽核分账、计费分析等多维度服务。平台承载腾讯公司收入大盘， 百亿级账户、百亿级日交易、覆盖180+个国家（地区）、服务数万业务和上百万商户，是一个全方位的一站式计费平台。     TDMesh 由支撑腾讯内部15年的计费技术体系孵化而来，包含全域一致性、海量请求支撑、724不间断服务管理、秒级的智能监控和弹性伸缩等多个功能板块，共同组成一套全面的金融级处理方案。   腾讯计费平台部总经理李纲表示：“基于计费的高一致、高性能、高可用、高可靠技术要求等挑战，腾讯计费平台部基于服务内部业务的多年经验，将核心技术板块全面优化整合，推出一套金融级的核心交易解决方案TDMesh。在不断自我进化持续打磨的同时，也希望通过参与相关技术讨论，与合作伙伴共同构建金融级高一致技术范例，推动行业发展。”*   应对 ”四高“ 挑战，腾讯计费的技术构建思路   腾讯计费系统的基础建设起步于 2004 年，在此后 15 年的发展过程中，随着接入业务增多、移动支付兴起、部署区域全球化

1.共享锁 (lock in share mode) 1.1 概念 允许不同事务之前共享加锁读取，但不允许其它事务修改或者加入排他锁 如果有修改必须等待一个事务提交完成，才可以执行，容易出现死锁 1.2 例子： 共享锁事务读取 以不同的 session 来举例： a: start transaction; select * from demo where id = 1 lock in share mode; b: start transaction; select * from demo where id = 1 lock in share mode; 此时 a 和 b 都可以正常获取结果，那么再加入 c 排他锁读取尝试 c: start transaction; select * from demo where id = 1 for update; 在 c 中则无法获取数据，直到超时或其它事物 commit 共享锁事务更新 a： update demo set name = 'xxx' where id = 1; 可以很快获取执行结果。当 b 再次执行修改 id=1 的语句时： b： update demo set name = 'yyy' where id = 1; 就会出现死锁或者锁超时，错误如下： Deadlock found when trying to get lock

Mysql 主要通过binlog 跟redolog 来保证数据的可靠性 binlog 的写入机制 binlog 的写入逻辑比较简单:事务执行过程中，先把日志写到 binlog cache，事务提交的时候，再把 binlog cache 写到 binlog 文件中 一个事务的 binlog 是不能被拆开的，因此不论这个事务多大，也要确保一次性写入。 这就涉及到了 binlog cache的保存问题。 系统给 binlog cache 分配了一片内存，每个线程一个，参数 binlog_cache_size 用于控制单个线程内 binlog cache 所占内存的大小。如果超过了这个参数规定的大小，就要暂存到磁盘。 事务提交的时候，执行器把 binlog cache 里的完整事务写入到 binlog 中，并清空 binlog cache write，指的就是指把日志写入到文件系统的page cache，并没有把数据持久化到磁盘，所以速度比较快 fsync，才是将数据持久化到磁盘的操作。一般情况下，我们认为 fsync 才占磁 盘的 IOPS write 和 fsync 的时机，是由参数 sync_binlog 控制的: sync_binlog=0 的时候，表示每次提交事务都只 write，不 fsync; sync_binlog=1 的时候，表示每次提交事务都会执行 fsync;

视图 1. 为什么要有视图 对于复杂的查询，往往是有多个数据表进行关联查询而得到，如果数据库因为需求等原因发生了改变，为了保证查询出来的数据与之前相同，则需要在多个地方进行修改，维护起来非常麻烦 解决办法：定义视图 2. 视图是什么 通俗的讲，视图就是一条SELECT语句执行后返回的结果集。所以我们在创建视图的时候，主要的工作就落在创建这条SQL查询语句上。 视图是对若干张基本表的引用，一张虚表，查询语句执行的结果，不存储具体的数据（基本表数据发生了改变，视图也会跟着改变）； 方便操作，特别是查询操作，减少复杂的SQL语句，增强可读性； 3. 定义视图 建议以v_开头 create view 视图名称 as select语句; 4. 查看视图 查看表会将所有的视图也列出来 show tables; 5. 使用视图 视图的用途就是查询 select * from v_stu_score; 6. 删除视图 drop view 视图名称; 例： drop view v_stu_sco; 8. 视图的作用 提高了重用性，就像一个函数 对数据库重构，却不影响程序的运行 提高了安全性能，可以对不同的用户 让数据更加清晰 事务 1. 为什么要有事务 事务广泛的运用于订单系统、银行系统等多种场景 例如： A用户和B用户是银行的储户，现在A要给B转账500元，那么需要做以下几件事： 检查A的账户余额

1 用途 事务方面的基类，如{ @link TransactionInterceptor}或AspectJ方面。 这使得底层的Spring事务基础结构可以很容易地用于为任何方面系统实现方面。 子类负责以正确的顺序调用该类中的方法。 注意：这个类不能实现Serializable，因为它是AspectJ方面的基类(不允许实现Serializable)! 2 类图 3 类核心方法 import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import org.springframework.beans.factory.BeanFactory; import org.springframework.beans.factory.BeanFactoryAware; import org.springframework.beans.factory.InitializingBean; import org.springframework.beans.factory.annotation.BeanFactoryAnnotationUtils; import org.springframework.core.NamedThreadLocal; import org