事务隔离级别

1.hibernate中的实体规则 　　1）实体类创建的注意事项 　　　　1>持久化类提供无参数构造 　　　　2>成员变量私有，提供共有get/set方法访问。需提供属性。 　　　　3>持久化类中的属性，应尽量使用包装类型。 　　　　4>持久化类需要提供oid.与数据库中的主键列对应。 　　　　5>不要用final修饰class 　　　　　　---hibernate使用cglib代理生成代理对象。代理对象是继承被代理对象。如果被final修饰。将无法生成代理。 　　2）主键类型 　　　　1>自然主键（少见） 　　　　　　---表的业务列中，有某业务列符合，必须有，并且不重复的特征时，该列可以作为主键使用。 　　　　2>代理主键（常见） 　　　　　　---表的业务列中，没有某业务列符合，必须有，并且不重复的特征时，创建一个没有业务意义的列作为主键。 　　3）主键生成策略 　　　　1>代理主键 　　　　　　---identity : 主键自增.由数据库来维护主键值.录入时不需要指定主键. 　　　　　　　　a. sequence: Oracle中的主键生成策略. 　　　　　　　　b.increment(了解): 主键自增.由hibernate来维护.每次插入前会先查询表中id最大值.+1作为新主键值. 　　　　　　　　c.hilo(了解): 高低位算法.主键自增

上篇文章(传送门: Hibernate学习笔记_01 )介绍了Hibernate是什么,如何搭建,配置文件详解以及Hibernate的一些基本API详解这几个方面做了简单介绍,那么本文将会从一下5个方面记录Hibernate的学习经历: 1.hibernate中的实体规则 2.hibernate中的对象状态 3.hibernate进阶—— 一级缓存 4.hibernate中的事务 5.hibernate中的批量查询(概述) Ⅰ.Hibernate中的实体规则 　　 在Hibernate使用中,需要创建与数据库表对应的实体,并在映射文件中配置.在创建实体的时候需要注意一些细节. 　　(1)实体类创建时需要注意5个事项: 　　　　 1.持久化类提供无参数构造 　　　　 2.成员变量私有,提供共有get/set方法访问.需提供属性 　　　　 3.持久化类中的属性,应尽量使用包装类型 　　　　 4.持久化类需要提供oid.与数据库中的主键列对应 　　　　 5.不要用final修饰class(hibernate使用cglib代理生成代理对象.代理对象是继承被代理对象.如果被final修饰.将无法生成代理.) 　　(2)主键类型 　　　　自然主键(少见):表的业务列中,有某业务列符合,必须有,并且不重复的特征时,该列可以作为主键使用. 　　　　代理主键(常见):表的业务列中,没有某业务列符合

http://luohonghong.blog.163.com/blog/static/78312058201142411533316/ SQLServer查看和解决死锁的方法 2011-05-24 11:05:33 | 分类： SQL | 字号 订阅 在master数据库中新建以下存储过程 --处理死锁 -- 查看当前进程,或死锁进程,并能自动杀掉死进程 -- 因为是针对死的,所以如果有死锁进程,只能查看死锁进程 -- 当然,你可以通过参数控制,不管有没有死锁,都只查看死锁进程 --调用示例 exec p_lockinfo create proc [dbo].[p_lockinfo] @kill_lock_spid bit=1, --是否杀掉死锁的进程,1 杀掉, 0 仅显示 @show_spid_if_nolock bit=1 --如果没有死锁的进程,是否显示正常进程信息,1 显示,0 不显示 as declare @count int,@s nvarchar(1000),@i int select id=identity(int,1,1),标志, 进程ID=spid,线程ID=kpid,块进程ID=blocked,数据库ID=dbid, 数据库名=db_name(dbid),用户ID=uid,用户名=loginame,累计CPU时间=cpu, 登陆时间=login_time

Java事务失效 问题复现，用伪代码复现问题！ 事务配置文件 < tx: advice id = " txAdvice " transaction-manager = " transactionManager " > < tx: attributes > <!-- TODO 事务隔离级别可以尝试 NESTED --> < tx: method name = " save* " propagation = " REQUIRED " rollback-for = " Exception " /> < tx: method name = " create* " propagation = " REQUIRED " rollback-for = " Exception " /> < tx: method name = " add* " propagation = " REQUIRED " rollback-for = " Exception " /> < tx: method name = " update* " propagation = " REQUIRED " rollback-for = " Exception " /> < tx: method name = " * " read-only = " true " rollback-for = " Exception " /> </

1. 死锁原理 根据操作系统中的定义：死锁是指在一组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态。 死锁的四个必要条件： 互斥条件 (Mutual exclusion) ：资源不能被共享，只能由一个进程使用。 请求与保持条件 (Hold and wait) ：已经得到资源的进程可以再次申请新的资源。 非剥夺条件 (No pre-emption) ：已经分配的资源不能从相应的进程中被强制地剥夺。 循环等待条件 (Circular wait) ：系统中若干进程组成环路，该环路中每个进程都在等待相邻进程正占用的资源。 对应到 SQL Server 中，当在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁；这些资源可能是 ：单行 (RID ，堆中的单行 ) 、索引中的键 (KEY ，行锁 ) 、页 (PAG ， 8KB) 、区结构 (EXT ，连续的 8 页 ) 、堆或 B 树 (HOBT) 、表 (TAB ，包括数据和索引 ) 、文件 (File ，数据库文件 ) 、应用程序专用资源 (APP) 、元数据 (METADATA) 、分配单元 (Allocation_Unit) 、整个数据库 (DB) 。 一个死锁示例如下图所示： 说明： T1 、 T2 表示两个任务； R1 和

前言 fescar发布已有时日，分布式事务一直是业界备受关注的领域，fescar发布一个月左右便受到了近5000个star足以说明其热度。当然，在fescar出来之前，已经有比较成熟的分布式事务的解决方案开源了，比较典型的方案如LCN（https://github.com/codingapi/tx-lcn）的2pc型无侵入事务，目前lcn已发展到5.0，已支持和fescar事务模型类似的TCX型事务。还有如TCC型事务实现hmily（https://github.com/yu199195/hmily）、tcc-transaction(https://github.com/changmingxie/tcc-transaction)等。在微服务架构流行的当下、阿里这种开源大户背景下，fescar的发布无疑又掀起了研究分布式事务的热潮。fescar脱胎于阿里云商业分布式事务服务GTS，在线上环境提供这种公共服务其模式肯定经受了非常严苛的考验。其分布式事务模型TXC又仿于传统事务模型XA方案，主要区别在于资源管理器的定位一个在应用层一个在数据库层。博主觉得fescar的txc模型实现非常有研究的价值，所以今天我们来好好翻一翻fescar项目的代码。本文篇幅较长，浏览并理解本文大概耗时30~60分钟左右。 项目地址 fescar：https://github.com/alibaba

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作为一名开发人员，在日常的工作中会难以避免地接触到数据库，无论是基于文件的 sqlite 还是工程上使用非常广泛的 MySQL、PostgreSQL，但是一直以来也没有对数据库有一个非常清晰并且成体系的认知，所以最近两个月的时间看了几本数据库相关的书籍并且阅读了 MySQL 的官方文档，希望对各位了解数据库的、不了解数据库的有所帮助。 本文中对于数据库的介绍以及研究都是在 MySQL 上进行的，如果涉及到了其他数据库的内容或者实现会在文中单独指出。 数据库的定义 很多开发者在最开始时其实都对数据库有一个比较模糊的认识，觉得数据库就是一堆数据的集合，但是实际却比这复杂的多，数据库领域中有两个词非常容易混淆，也就是 数据库 和 实例 ： 数据库：物理操作文件系统或其他形式文件类型的集合； 实例：MySQL 数据库由后台线程以及一个共享内存区组成； 对于数据库和实例的定义都来自于 MySQL 技术内幕：InnoDB 存储引擎 一书，想要了解 InnoDB 存储引擎的读者可以阅读这本书籍。 数据库和实例 在 MySQL 中，实例和数据库往往都是一一对应的，而我们也无法直接操作数据库，而是要通过数据库实例来操作数据库文件，可以理解为数据库实例是数据库为上层提供的一个专门用于操作的接口。 在 Unix 上，启动一个

1、概述 事务就是对数据库数据进行更改（包括insert、update、delete等）操作的一个执行单元，通常有一条或多条更改语句组成。在同一个事务中的更改操作要么同时成功，要么同时失败。 事务具有4个属性：原子性、一致性、隔离性、持久性。即 ACID 特性。 原子性（atomicity）：同一个事务中的更改操作要么同时成功，要么同时失败。 一致性（consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态。 隔离性（isolation）：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的。 持久性（durability）：指一个事务一旦提交，对数据库中数据的改变就应该是永久性的。 下面我们详细介绍一下隔离性。 2、四个隔离级别 MySQL 中有四个隔离级别： READ UNCOMMITTED 读未提交，一个事务内部可以读到其他事务未提交的更改，可能出现“脏读” READ COMMITTED 读已提交，一个事务内部可以读到其他事务已提交的更改，这个比较常用 REPEATABLE READ 可重复读，InnoDB引擎默认使用的隔离级别。一个事务内部不能读到其他事务做的任何更改，可能出现“幻读” SERIALIZABLE 串行化，不支持并发 3、修改事务隔离级别 MySQL 的 InnoDB 引擎默认使用的是

2、InnoDB支持的四种事务隔离级别名称是什么？ 之间的区别是什么？ 1、读未提交：可以读取到其它会话未提交的数据 2、读已提交：允许不可重复读，但不允许脏读。提交后其它会话可以看到提交的数据。 3、可重复读：禁止不可重复读和脏读，以及幻读（innodb独有） 4、可串行化：事务只能一个接一个执行，但不能并发执行，事务隔离级别最高。 区别： 3、聊一聊事务的特性 事务的特性：原子性：事务中的各项操作，要么全做要么全不做 一致性：事务结束后系统状态是一致的 隔离性：并发执行的事务彼此无法看到对方的中间状态 持久性：事务完成后所作的改动都会被持久化，即使发生灾难性的失败。通过日志h和同步备份可以在故障发生后重建数据。 6、谈一谈对慢查询的分析？MySQL常用的优化方法有哪些？ 分析：1、是否遇到行锁，表锁 2、没有建索引或者创建了索引没有用到 3、数据库在刷新脏页 优化：1、使用正确的字段类型 2、使用连接查询来代替子查询，但是不能大量使用join，（可以使用单表查询，然后将查询结果在应用程序中进行关联） 3、使用事务 4、使用limit进行分页操作 5、使用索引，（前导模糊查询不能使用索引，b避免使用!=、或not in或<>等否定操作符，字段的默认值不要未null，在字段上进行计算不能命中索引，避免使用or） 7、谈一谈悲观锁和乐观锁以及SQL的实现 悲观锁

Mysql存储引擎 1.MyISAM MySQL 5.0 之前的默认数据库引擎，最为常用。拥有较高的插入，查询速度，但不支持事务. 2.InnoDB事务型数据库的首选引擎，支持ACID事务，支持行级锁定, MySQL 5.5 起成为默认数据库引擎. 3.BDB源 自 Berkeley DB，事务型数据库的另一种选择，支持Commit 和Rollback 等其他事务特性 4.Memory所有数据置于内存的存储引擎，拥有极高的插入，更新和查询效率。但是会占用和数据量成正比的内存空间。并且其内容会在 MySQL 重新启动时丢失 5.Merge将一定数量的 MyISAM 表联合而成一个整体，在超大规模数据存储时很有用 6.Archive非常适合存储大量的独立的，作为历史记录的数据。因为它们不经常被读取。Archive 拥有高效的插入速度，但其对查询的支持相对较差 7.Federated将不同的 MySQL 服务器联合起来，逻辑上组成一个完整的数据库。非常适合分布式应用 8.Cluster/NDB高冗余的存储引擎，用多台数据机器联合提供服务以提高整体性能和安全性。适合数据量大，安全和性能要求高的应用 9.CSV 逻辑上由逗号分割数据的存储引擎。它会在数据库子目录里为每个数据表创建一个 .csv 文件。这是一种普通文本文件，每个数据行占用一个文本行。CSV 存储引擎不支持索引。 10