博客园_Richie

SQL Server用错关联方式

2010-09-26T09:51:00Z

SQL Server中不少怪异问题都是由用错关联方式引起的，从2000到2005有所改善，但2005的查询优化引擎还是存在“犯傻”的时候

1. 问题1
现象：一个存储过程，通过一个服务程序调用，长时间不能结束，数据库服务器显示该存储过程执行到某个语句时一直等待在那，数据库服务器内存充足，CPU消耗几乎没有。把这个存储过程拿出来直接在查询分析器中执行，参数跟程序调用时完全类似，立即结束且结果正确
解决方案：排除了阻塞等原因，因为放在查询分析器中执行时一切正常，从执行计划等方面无法看出任何问题，也排除了磁盘IO等方面的原因，实在想不到其他的了。最后怀疑是SQL Server查询引擎JOIN方式选的不对，强制使用HASH JOIN后，程序调用恢复正常
疑点：一直没有发现程序调用与直接使用查询分析器执行，这2者之间存在哪些差别，会影响到SQL Server查询优化决策

2. 问题2
现象：一个不算复杂的查询，用到了row_number函数分页，一执行就会导致服务器8个CPU全部100%，很长时间（好几分钟）不能结束。使用临时表实现同样的效果，几秒钟完成
语句1：
   SELECT
      ROW_NUMBER() OVER(ORDER BY COLUMNNAME1 ASC) as FC_ROWNUMBER
      ,COUNT(1) OVER() AS FC_COUNT
      ,* FROM (
      SELECT 产品 as COLUMNNAME1,产品描述 as COLUMNNAME2,入库日期 as COLUMNNAME7,预期数量 as COLUMNNAME8
         ,入库数量 as COLUMNNAME9,行状态 as COLUMNNAME10,供应商 as COLUMNNAME11,供应商名称 as COLUMNNAME12
      FROM V_收货明细查询
      where   入库日期 >= '2010-7-1'
   ) TT_MAINKEY_TMP
执行计划：

语句2：
SELECT * FROM (
   SELECT
      ROW_NUMBER() OVER(ORDER BY COLUMNNAME1 ASC) as FC_ROWNUMBER
      ,COUNT(1) OVER() AS FC_COUNT
      ,* FROM (
      SELECT 产品 as COLUMNNAME1,产品描述 as COLUMNNAME2,入库日期 as COLUMNNAME7,预期数量 as COLUMNNAME8
         ,入库数量 as COLUMNNAME9,行状态 as COLUMNNAME10,供应商 as COLUMNNAME11,供应商名称 as COLUMNNAME12
      FROM V_收货明细查询
      where   入库日期 >= '2010-7-1'
   ) TT_MAINKEY_TMP
) TT_RET_TMP
WHERE FC_ROWNUMBER BETWEEN 1 AND 1000
ORDER BY COLUMNNAME1 ASC
执行计划：

仅仅是把SQL作为一个子查询，在外面多包装了一下，整个查询计划就不一样了。排除了统计信息不准确、索引碎片等状况
2个查询计划中对3个表使用的都是聚集索引扫描，基本上就是关联算法不一样
因为用的并行查询，三个表数据都有几十万和一百多万，嵌套循环需要执行几十万次，所以单个查询导致所有CPU都100%。估计高CPU是由于Lazy Spool操作造成的

解决方案：
强制用HASH JOIN，或者加索引避免SQL Server出错，或者用临时表绕过去

本文链接

事务信息系统-并发控制与恢复的理论, 算法与实践-计算模型, 并发控制部分

2010-09-15T14:51:00Z

事务信息系统-并发控制与恢复的理论, 算法与实践

页的存储结构

图：数据库页的存储布局页是磁盘与主存间传输数据的最小单元，也是内存中进行缓存的单元
页头（page header）包含页内空间管理的一些信息，比如空闲空间字节数、最大空闲区域大小等

页槽Slot Array的作用：
varchar等变长类型字段的更新操作等，可能导致记录在页内移动，如果外部直接以数据记录的物理地址进行引用，记录移动时处理非常复杂，所以在中间添加一个隔离层Slot Array。Slot Array中存放页内数据的实际地址，以页号+槽号形成RID，外部均以RID引用数据记录
数据在页内移动时只需要更新Slot Array中的实际地址即可，页间移动可以使用一个Forwarding RID实现，例如上图中的示例
对于包含BLOB等长字段类型的记录，简单技巧可以将列的实际数据存储在其他多个页中，而在记录实际数据位置存储页号列表

一次磁盘IO可以读取一个或多个连续的页，可以一次读取的固定数目的页称作块（block），在数据库理论中块和页等同对待
数据库系统通常以区间（extent）为单位预先分配磁盘空间（一次预先分配一个或多个区间），区间是多个连续页。注意区间和块的区别
存储层需要保存必要的元数据，例如将页号转换成物理磁盘地址、空闲空间管理等。通常使用区间表（extent table）来完成页号与物理磁盘地址的转换

计算模型 Computational Models
页模型page model
也称作读写模型read/write model，是一种简单模型。例如事务t使用页模型定义类似如下：t=r(x)w(x)r(y)r(u)w(y)，其中r表示读取数据页，w表示写数据页，对于存储层而言一个事务就是这样一个读写序列或偏序
页模型通过简明优雅的方式抓住并发控制与恢复的实质，可以描述很多系统实现中的重要问题，局限在于仅以低层页的读写操为元素，没有表达数据访问操作的语义

对象模型object model
对象模型在页模型的基础上考虑高层操作，在对象模型中事务由ADT（abstract data type）操作构成，最终仍归于低层页的读写
下面是一个对象模型示例图：

图：对象模型示例示例场景说明如下：

    * 事务t1中先执行一个select语句，找出住在城市Austin的人员，然后执行一条insert语句，插入一条住在城市Austin的人员信息
    * 假设表中只有一个索引，位于城市这个字段，使用的B+ tree结构，索引结构只有2层

ADT操作以及页的读写说明如下：

   1. Search('Austin'): select语句使用城市的索引查找符合Austin的索引项，得到RID列表
          * r(r): 读取B+ tree索引根节点页
          * r(l): 读取B+ tree索引叶节点页
   2. Fetch(x), Fetch(y): 根据RID列表加载数据x、y所在的数据页，得到数据记录x、y
          * r(p), r(q): 分别读取RID x和y所在的数据页p和q
   3. Store(z): 插入记录z
          * r(f): 读取存储层的元数据页f，其中记录了空闲空间信息
          * r(p): 从页f上得到页p具有足够空间插入记录z，这里读取这个页p
          * w(p): 把记录z写入页p，并将页p写回磁盘
          * r(r), r(l), w(l): 更新城市字段的索引，读取索引根节点页r、叶节点页l，更新叶节点页l并写回磁盘

对象模型事务t是一棵树，用事务标识符标记根节点，用被调用的操作名称、参数标记非叶节点，用页模型的读写操作标记叶节点
如果将事务的操作序列看成全序，则这个事务只能串行执行；如果将其看作偏序，则其中某些操作可以并行执行

经典并发问题
脏读dirty-read、不一致读inconsistent-read、幻象读phantom-read参考Transaction, Lock, Isolation Level
更新丢失lost-update：

图：丢失更新问题

页模型上的并发控制 - 调度协议
页模型的可串行性理论有终态可串行性、视图可串行性、冲突可串行性等，由于判定终态可串行性和视图可串行性的复杂度太高，因此商业数据库基本都采用冲突可串行性CSR类进行判定
概念：
历史history：指一个完整、已经结束的事务，即事务要么使用commit提交了，要么使用abort终止了
调度schedule：指未完成的事务，即历史的一个前缀

图：Transaction Scheduler图：事物调度器 Transaction Scheduler
client 1、client 2等代表不同事物的操作序列
事务管理器TM主要任务是事物登记，管理trans、commit、abort、active列表，维护ready-to-execute列表等
调度器从TM接收输入调度，将其转化为可串行化的输出调度
调度器分为乐观的、悲观的

死锁处理
一般基于等待图waits-for graph WFG概念，WFG中存在环路时即发生死锁
死锁检测：持续检测continuous detection、周期检测periodic detection
死锁处理方法一：允许发生死锁，从死锁中选出牺牲者消除WFG环路；处理方法二：死锁预防，即不允许死锁情况发生

两阶段封锁协议 - two-phase locking protocol - 2PL
对每个事物，加锁阶段严格区别于紧接着的释放阶段，该封锁协议就是两阶段的
即可以明确的将事务分成前后两个部分，在前面部分只存在加锁，不存在锁释放，而在后面部分则只存在锁释放操作，没有加锁操作。商业数据库考虑性能问题不会严格按照2PL协议实现。SQL92不同的隔离级别本身就是性能与可串行性之间的一个取舍平衡，另外页模型并没有考虑到语义方面，商业数据库部分结合语义方面之后也能对封锁协议进行改造优化以换取性能

图：2PL下锁增长和缩减阶段示意图图：2PL下锁增长和缩减阶段示意图

2PL协议具有C2PL、S2PL、SS2PL几种变体
下面是一个2PL调度器的调度示例：

图：调度示例图：2PL调度器调度示例
顶部的s是输入，底部3行是经过2PL调度器的一种可行的输出
下表1、2、3等表示不同的事物t1、t2、t3等，wl表示加写锁，wu表示释放写锁，rl表示加读锁，ru表示释放读锁，c表示事物结束（commit）
中间部分锁的持有时序图中，虚线部分表示锁冲突时的等待时间

保守2PL - Conservative 2PL - C2PL
在事物开始时对所有需要访问的数据获取锁。这个协议只能在有限的应用场景下使用，他不存在死锁问题，因为事物要么等待不能开始，要么就已经得到了全部所需的锁了

图：C2PL下锁增长和缩减阶段示意图图：C2PL下锁增长和缩减阶段示意图

严格2PL - Strict 2PL - S2PL
事物一直持有已经获得的所有写锁，直到事物终止

图：S2PL下锁增长和缩减阶段示意图图：S2PL下锁增长和缩减阶段示意图（假设事物中的锁都是写锁）

强2PL - Strong 2PL - SS2PL
事物获得的所有锁（包括读锁和写锁）被一直保持直到事物终止。这种情况下锁的增长和缩减阶段与S2PL相同，不过不局限于写锁

有序共享2PL - Ordered Sharing 2PL - O2PL
在2PL中，如果对同一个数据项申请的锁，与这个数据项上面已经存在的锁不相容时，就只能等待
有序共享相容性规则：同一个数据项上的两个锁无论是否冲突，只要锁操作与相应的数据操作均以相同的顺序执行就可以被不同事物同时持有。这个规则以固定的顺序对数据项进行操作为前提，从而放宽了锁相容性规则，理论上证明是可行的，但他必须强制数据访问的顺序，需要额外的数据结构和运行时代价，实际中比较少采用

利他锁 - Altruistic Locking - AL
是2PL的一种扩展协议。某些事物时间可能很长，持有大量的锁，这样可能阻塞大量其他短事物。如果短事物访问的仅仅是长事物已经处理过的数据项的子集，则长事物将这部分数据项捐赠给其他事物访问

非两阶段封锁协议
有只写封锁树 write-only tree locking WTL、读写封锁树read/write tree locking RWTL等，他们只能在对数据项的访问遵从特定的顺序的情况下使用，比如对数据项的访问呈树状方式
WTL在封锁规则的基础上添加了两条附加规则：只有在持有父项数据写锁的情况下，才能获取子项数据的写锁；事物对释放某个数据项的写锁之后，不能在获得该数据项的写锁。这确保了数据更新处理将沿着树的某一路径从根节点向叶节点进行，锁的范围可以限制在某个子树范围内。锁的申请和释放并不是两阶段的，沿着数的路径向子树进行时，父项的锁可以释放，即锁的申请和释放可以交替进行
WTL协议是无死锁的，对RWTL协议规则稍作修改可以导出DAG封锁协议DAG locking protocol

时间戳排序协议 - timestamp ordering protocol - TO
不使用封锁，基本规则是对不同事物冲突的操作，严格按照事物开始时间的先后关系进行调度
在封锁协议中通过锁机制检测冲突，在TO中也需要有额外的信息用于检测冲突。例如Ti在Tj之前开始，调度器先对Tj输出了一个调度qj(x)，但后来 Ti发送过来一个pi(x)的操作，与qj(x)冲突（即按照TO规则，pi(x)必须在qj(x)之前执行，但在pi(x)之前qj(x)已经被调度输出了），所以调度器需要记录信息以检测这种冲突并作出相应处理（例如阻塞Ti，等待Tj结束后再开始）

SGT协议 - Serialization Graph Tester - 可串行化图检测器
维护一张SGT图，图中并发的每个事物拥有一个节点，事物Ti的操作与Tj冲突，如果Tj中发生冲突的操作已经输出了，则由Tj向Ti添加一条有向边，Ti进入等待状态。如果事物Ti的某个操作导致SGT图中存在环路，则输出是不可串行化的，事物Ti需要取消
实际中SGT协议需要维护的额外数据量以及运算量都比较大，对于调度器而言无法接收，所以很少采用

对象模型上的并发控制，搜索结构上的并发控制
......

多版本并发控制 - multiversion concurrency control
单版本时数据库中的每个数据项只有一个副本，而多版本时则会为数据项同时维护多个版本，而多版本对于client是透明的，对client而言数据库仍然只维护了数据项的一个副本。通过对并发控制算法的扩展调整，多版本同样可以达到可串行性目标，他仅仅是并发控制的另一种处理方式。他的优点是可以降低封锁协议中锁的使用，极大的提高并发处理性能，并给数据恢复等方面带来好处

多版本时间戳排序协议 - multiversion timestamp ordering protocol - MVTO
本质上类似FIFO方式处理并发操作。每个事物按照事物开始时的时间戳排序，基于这个顺序处理调度和冲突
下面对的规则描述中，Ti表示第i个事物；ts(Ti)表示第i个事物的时间戳；Ri(X)表示Ti读取数据项X；Xk则表示数据项X的某一个版本，他是由事物Tk写入的；ts(Xk)表示数据项的Xk这个版本的时间戳，他就是事物Tk的时间戳，即ts(Xk)=ts(Tk)。下面是MVTO规则：

   1. Ri(X)将被转化为Ri(Xk)，即需要明确读取数据项X的哪一个版本，其中Xk应该为ts(Xk)<ts(Ti)的一个最新版本。另外Xk可能是已提交的版本，也可能是未提交的版本
   2. 处理Wi(X)时，如果已经存在一个Rj(Xk)操作，并且时间戳关系为ts(Xk)<ts(Ti)<ts(Tj)，则Wi(X)被拒绝，Ti将被取消，因为这样存在冲突，将造成不可串行化的结果。否则，Wi(X)被转化为Wi(Xi)并执行，即为数据项X生成一个新的版本Xi
   3. 可选规则：延迟提交。这是在不允许脏读的情况下用来避免产生脏读的一个机制。如果事物Ti读取了Tj写入的某个数据项，即存在Ri(Xj)操作，则事物Ti的提交操作Ci需要被推迟到事物Tj成功提交之后再执行。如果事物Tj失败则事物Ti也失败（或重做）

下面是MVTO协议下的一个执行示例，可以使用上面的规则进行解释：

图：MVTO协议下的执行示例

    * 事物t3中因为存在r3(x2)操作，即读取了x2这个未提交的版本（按照规则1，他应该读取x2的），所以他的提交被延迟（虚线表示等待），在t2提交之后再提交
    * t4被终止是因为规则2的作用，因为t5中存在r5(y2)这个操作，如果让w4(y4)成功，则事物t5可能出现不一致读的情况，不是一个可串行化的调度。图来自原书，图中应该有个错误，r5(y2)不可能出现在w2(y2)前面的，他应该位于w2(y2)与w4(y4)之间才对
    * 最后看一下t1，在读取y的时候，根据MVTO的规则1，应该读取y0这个版本。这样在没有加锁的情况下实现了事物t1的一致性读，但他并没有利用锁阻塞t2、t4（两阶段封锁协议的情况下他们的写操作与t1的读锁冲突），而是让t2、t4并行执行。根据MVTO规则，t1不能有写x、y的操作，否则按照规则2应该取消t1。这样从理论上看存储层还是可以保证x、y的可串行性结果的，但存在一个疑问是：如果t1有其他写操作，比如 w1(u1)，而u1是基于x、y的运算而来，即u1=f0(u)f1(x)f2(y)，如何确保数据项u的可串行性结果呢？还有对外部而言t1实现了对 x、y的一致性读，但w2(y2)成功了，外部基于x、y得来的计算结果可能就是一个不正确的值，如何确保一致性？

另外还有多版本两阶段封锁协议 - multiversion 2PL locking protocol - MV2PL、只读多版本协议 - read-only multiversion protocol - ROMV等

暂态版本化 - Transient Versioning
暂态版本化的做法是将数据项的最新版本放在数据记录位置上，数据项以前的旧版本都放在版本池version pool中，版本池可以驻留内存或者磁盘。这样当访问最新版本数据时没有性能损失，版本池也方便对旧版本的垃圾回收。有些系统中把版本池跟用于恢复的日志项合并在一起。版本池也叫做回滚段rollback segment

图：暂态版本化的存储组织图：暂态版本化的存储组织
数据项的每个版本包括两个额外的字段，一个是创建时间戳，另一个是指向前一版本的指针

    * 对于新增的数据项，还没有旧版本，因此在当前版本中指针为空，例如图中的1135
    * 删除的数据仍然保留在当前版本位置上，但会打上删除标记，例如图中的1141
    * 同一个数据项的各个版本组成一个链表

另一种方法是在数据项的当前版本中维护一个小的版本选择表，其中包含每个版本的时间戳以及一个指向该版本位置的指针
如果一个数据项的旧版本再也不会被当前活动的事务使用到，则这些旧版本就成为垃圾，可以被回收掉

关系数据库的并发控制
面向谓词的并发控制 - Predicate-Oriented Concurrency Control
封锁协议是针对页、数据项加锁，而面向谓词的并发控制是针对操作加锁，更具体的是针对操作的谓词加锁。例如：
    select name from persons where age>30
则将age>30与锁关联
面向谓词的并发控制是比较早提出来的一种想法，后来也经过了不少研究，他的问题在于检测两个谓词是否兼容是一个NP完全问题，成本太高，但在特定场景下，例如B+树上的并发控制，具有实际意义

实现和实用性问题
通用的锁管理器数据结构

图：锁管理器的数据结构
锁管理器需要达成的目标：

   1. 请求锁时可以检验冲突
   2. 释放锁时，需要将资源授予被该锁阻塞的其他锁
   3. 事务终止时释放该事务的所有锁

锁管理器的数据结构常驻内存，由resource ID索引的哈希表存放已经加锁以及需要加锁的资源ID
每个哈希表项指向一个资源控制块RCB，RCB中的hash chain用于解决hash冲突
对于共享锁，多个锁可以同时被同一资源持有，多个锁请求（例如冲突的写锁）可能正在等待被授予该资源上，这样在同一个资源上将形成一个已持有的共享锁列表以及等待被授予的排他锁与共享锁队列，因此在RCB上会指向一个锁控制块LCB的链接表，即上图中的FirstInQueue, NextInQueue链表
为了达成第3点，为每个活动事务维护一个事务控制块TCB，同样使用链表将该事务的所有锁链接起来，即上图中的LCB chain构成的链表

锁的数据结构将是数据库中访问最频繁的地方之一，因此需要控制这个内存数据结构的大小来避免性能问题，所以一般数据库中存在锁粒度升级的处理方式。如果一个事务已经持有了大量细粒度的行锁，数据库可能会将锁粒度升级为页锁或者表锁，以减小锁管理器的内存空间
使用了不同粒度的锁，就存在不同粒度之间相容性的判断问题，所以引入了意向锁，参考数据库系统 - 面向应用的方法

本文链接

数据库系统 - 面向应用的方法

2010-09-15T14:25:00Z

数据库系统-面向应用的方法

一些概念
关系、元组、属性
在关系数据库理论中，关系 (relation)对应于数据库技术的表 (table)，元组 (tuple)对应于行 (row)，属性 (attribute)对应于列 (column)
元组的元 (arity)为属性数量，即列的数量，一元unitary，二元binary，三元ternary等
关系的势 (cardinality)为关系中的元组数量，即行数

Projection operator 投影运算
即选取仅选取部分列的查询

Materialized view 物化视图
即被高速缓存的视图

RAID
Redundant Array of Independent Disks，廉价磁盘冗余阵列。利用拆分（striping）提高性能，使用冗余提高可靠性。参考RAID on wikipedia
RAID0

RAID0块级拆分，没有冗余。拆分的文件支持并发存取，但任何一块磁盘损坏将导致所有文件损坏

RAID1

RAID1仅做冗余，没有拆分。支持并发读取，提高了读取性能，写入时需要同时写入多块磁盘

RAID2

RAID2字节级拆分（文件相邻的字节均被拆分存储到不同磁盘中），有一块或多块奇偶校验盘（图中的Disk 4, 5, 6）用于容错

RAID3

RAID3字节级拆分，有一块独立的奇偶校验盘（图中的Disk 3）

RAID4

RAID4块级拆分，有一块独立的奇偶校验盘。任何一块磁盘损坏不会造成数据丢失，2块盘损坏时将丢失数据

RAID5

RAID5块级拆分，具备奇偶校验，但没有独立的奇偶盘，奇偶校验与文件数据一起被拆分在多个盘中。任何一块磁盘损坏不会造成数据丢失，2块盘损坏时将丢失数据

RAID6

RAID6块级拆分，有2块奇偶盘，最多在2块磁盘损坏时不会造成数据丢失

存储
堆文件 heap file：记录无序，仅在末尾添加，删除记录时不释放空间，不适合查询
顺序文件 sorted file：按某些列的顺序存放，可运用二分查找等优化算法
填充因子 fill factor：每页预留空间供插入操作，预留空间满了以后使用溢出链overflow chain支持插入操作

索引
集成索引 integrated index：索引条目跟数据记录集成在一起
聚集索引 clustered index：对于有序索引（B+ tree等），如果索引条目与数据记录都是按照相同的search key排序的，则为聚集索引，集成索引是一种聚集索引；对于散列（hash）索引，如果散列索引条目就是数据记录则为聚集的，此时hash bucket本身就是数据文件的存储结构，数据文件就是hash bucket的序列
聚集索引通常又称为main index，非聚集索引又称为secondary index
稠密索引 dense idnex：索引条目与数据记录一一对应
稀疏索引 sparse index：索引条目与数据页一一对应（与数据记录为一对多关系）

ISAM: Indexed Sequential Access Method
ISAM结构示意图：

ISAM结构示意图非页节点称为分隔符级，一个分隔符节点示意图如下：

ISAM分隔符节点示意图其中Pn为指向下一级节点的指针，Kn为搜索码的值。Pi-1指向的K值<Ki<=Pi指向的K值

ISAM的分隔符级节点一旦创建便不再更改，因此ISAM被称为静态索引。叶子页中的条目被除时其空间不会释放，相关的分隔符级也不会更新，即可能出现分隔符级页中出现的某些search key在叶子节点上没有对应条目。插入时叶子页使用fill factor和overflow chain
ISAM对相对静态的表有效，动态表通常不用ISAM索引

B+ Tree
B+ tree结构示意图：

B+ tree结构示意图根节点到达任何一个叶子页的级数是一样的。叶子页添加了兄弟指针，方便range search，支持范围搜索、等值搜索、部分码搜索方式
叶子页至少包含(n-1)/2个值，最多包含n-1个值。维护B+ Tree结构（插入、删除操作等）算法复杂
节点与ISAM类似：

B+ tree节点示意图

Hash索引
只能等值搜索，这种情况下比B+ tree更有效
也需要使用overflow chain
有静态散列算法、动态散列算法（包括可扩展散列、线性散列）

Bit map 位图索引
位图索引一般用于低势属性（取值范围很小的属性）
为每一个取值建立一个位图向量，每一位对应于数据的某一行。例如有PERSON表SEX列，取值范围为(MALE, FEMALE)，数据4000行，则将建立2个位图向量V(male)、V(female)，每个向量有4000位。如果V(male)i=1则表示第i 行记录SEX列取值MALE
现在假如有这样一个查询：SEX='MALE' AND SMOKE='YES'，如果这2个列都有位图索引，则可以用V(sex-male) & V(smoker-yes)这个运算（位AND运算）得到满足条件的行
位图索引存在空间浪费，但特定情况下效率很高。另外位图索引的维护成本比较高，因此不适合频繁插入、更新的表

查询优化器
Rule based optimizer：基于既定的规则优化查询计划
Cost-based optimizer：在RBO的基础上增加统计信息，结合评估成本与既定规则优化查询计划

事物
有关事务的部分内容可以参考事物、锁、隔离等级
在数据库理论中检验事物正确性以完全串行化执行结果为基准，考虑并发处理后采用两阶段封锁协议(two-phase locking protocol, 2PL)，访问资源（读、写）时先申请锁
考虑并发性能问题，锁分成不同的粒度，典型的为表级锁、页级锁、行级锁

为什么需要意向锁？
因为有不同粒度的锁存在，为了优化锁冲突的判断处理而设计出意向锁
比如事物t1更新了某条记录，对这条记录加了写锁。而事物t2需要读取这个表的所有记录，需要对表加读锁。事物控制器如何确定这2个事物的加锁请求是否冲突？
有了意向锁之后，事物t1在更新记录时，对这个表加意向排他锁IX（如果有页锁，则对数据记录所在页也加IX锁）；事物t2申请这个表上的共享锁S时，就只需要检测表（以及页）上面已存在的锁是否与S锁冲突，而IX与S是冲突的，所以t2只有等待。这样避免了锁冲突判断时需要理解并处理加锁对象的类型以及之间的关系

意向锁类型
IS, Intention Shared, 意向共享锁：对行取读锁S时，则必须获取表的IS锁
IX, Intention Exclusive, 意向排他锁：要更新某一行，则必须先获取该表的IX锁
SIX, Shared Intention Exclusive, 共享意向排他锁：例如要更新某些行，但必须执行表扫描才能确定具体需要更新的行，则加SIX锁，它是共享锁与意向排他锁的结合

先写式日志 Write-ahead log
更新记录 update record：用于确保事物的原子性、持久性机制，事物终止（rollback）时可以根据更新记录回滚。更新日志中包含before image，即记录被更新之前的状态，因此可以用它来撤销更改。因此更新记录也被称为undo record
日志示意图：

数据库日志示意图 Ui：事物Ti的更新记录 update record
Bi：事物Ti的开始记录 begin record
Ci：事物Ti的开始记录 commit record
Ai：事物Ti的开始记录 abort record
CK：Check Point

   1. 终止事物时，在日志中反向扫描处理到该事物的begin record就完成了
   2. 系统崩溃时需要将当时所有活动事物全部回滚（系统崩溃时内存信息已经丢失，只能根据日志操作），所以用commit record、abort record标识那些已经结束了的事物
      另外，除非反向扫描完整个日志文件，否则无法确定崩溃时哪些事物为活动事物，因此在日志中定期记录check point record，用来记录检查点时刻系统中所有活动的事物id。这样崩溃恢复时只需要反向扫描到任何一个check point record就有方法确定扫描的终止条件

更新数据时，先更新数据文件还是先写日志？
如果先更新数据文件，在日志文件还没有写入时发生崩溃，则这个数据可能无法恢复；如果先写日志，在数据未更新时发生崩溃，则恢复处理不会造成数据错误。因此叫做write-ahead log
除了before image外，日志可能还包括after image，即记录更新之后的状态，用于重做事物，因此也叫redo record。例如某时刻数据库损坏，则可以用之前的某个备份加上redo log恢复到崩溃之前的某个状态，将损失降到最低

本文链接

Data Modeling Technologies - ER, IE, Barker, IDEF1X, EXPRES-G, ORM

2010-09-13T02:10:00Z

Entity Relationship Model - ER模型 - 实体关系模型
1976年Peter Chen首次提出了Entity Relationship Modeling（实体关系建模）概念，并发明了陈氏表示法Peter Chen's Notation，因此ER模型也可以叫做Chen's Model（陈氏模型）。下面是一个ER模型（ERD - ER diagram - Entity Relationship diagram）示例：

图：ER模型 - Peter Chen's Notation图：ER模型 - Peter Chen's Model，实际上这是一个EER - Enhanced Entity-Relationship Model，扩展ER模型
Entity 实体：使用方框表示
Attribute 属性：使用圆或椭圆表示。实体和实体关系都可以拥有属性，例如图中的Order-Line关系拥有3个属性

Relationship 关联关系：使用菱形表示，菱形中写上关联关系的名字
ER模型中关联关系也可以拥有属性，在多对多关联关系中不需要使用额外中间关联实体来表示，关联关系本身就可以作为这个中间实体。另外ER模型的关联关系不限于2个实体之间，可以在多个实体间使用一个关联关系

Unique Identifier 唯一标识
陈氏表示法没有很好的解决唯一标识问题，仅使用一种简单的标记方法，下图表示Party的ID作为Purchase Order唯一标识一员的情况，关联关系名称改为E，朝依赖实体方使用一个箭头，依赖实体使用一个额外的方框括起来

图：ER模型中唯一标识的表示方法图：ER模型中唯一标识的表示方法

Sub-type 子类型
最初的陈氏表示法中不包含子类型概念，后来Robert Brown和Mat Flavin添加了子类型表示法，这种ER模型称为扩展ER模型。上图ER模型中有一个子类型例子，超类Party派生出子类Organization和 Person

Constraints between relationships 关联关系的约束
最初的陈氏表示法中关联关系的每一端只使用一个数字表示，比如一对多的关联关系，在一端使用1，另一端实体上使用n表示，这对关联关系约束不充分。上图的 ER模型在关联关系每一端使用2个数字表示，这与Crow's Foot表示法以及UML中的optionality（可选项）、cardinality（关联基数）有些类似又有较大的区别，详细说明如下：

    上图中一个Purchase Order必须关联一个Party，必须关联一个或多个Order Line，每个Order Line要么是一个Product要么是一个Service
    Purchase Order右边的(1,)1表示一个Purchase Order有且必须有一个Party
    Party左边的(0,)n表示一个Party可以拥有多个Purchase Order，也可以没有
    Purchase Order左边的(1,)n表示Purchase Order必须有一个或多个Order Line
    Order Line右边的(1,)1表示每个Order Lien必须属于一个Purchase Order
    Order Line下面的(1,)1和菱形符号一起表示每个Order Line要么是一个Product要么是一个Service
    Product和Service上面的(0,)n表示Product和Service可以属于0个或多个Order Line
    Event和Event Category的关联关系稍特殊（实际中这种 n:1 的关系不多见），他不是一个普通的多对一关系。Event可以关联一个Event Category也可以不关联，而Event Category则必须关联一个或多个Event

Order-Line和Product、Service之间是一个exclusive or约束（异或、互斥约束，disjunctive mandatory约束）关系，使用超类和子类一样的表示法来表示。因为exclusive or的语义本身已经已经表明Order Line必须是Product或者Service其中之一，因此上图中Order Line右边和下面的(1,)1是多余的

EER - Enhanced Entity-Relationship Model 扩展ER模型
上面已经有些内容不属于最初的陈氏表示法，是后来其他人扩展的。陈氏表示法出现的早也存在一些不足，因此存在一些扩展以弥补缺陷，不同文档中使用的ER图也不尽相同，例如下图是wiki上的一个示例ER模型

图：Wiki上的ER模型示例图：Wiki上的ER模型示例
属性带下划线表示主键属性；关联关系连接线为两条线的表示"最少一个，或多个"（用于n的一端）；实体和关联关系使用两个框的，可能是上面讲到的唯一标识表示法，也可能是"最少一个，或多个"表示法的一部分（这一点有待确认）。还有一些，例如属性与实体间用两条线连接的表示该属性为多值属性（上图中Region实体的Foliage属性）。图中的部分解释如下：

    1 Account has n(at least one) Character, Account的AcctName属性将成为Has的唯一标识的一员;
    1 Region contains n(at least one) Character, Region的RegionName属性将成为Character的唯一标识的一员;

Information Engineering - IE模型
Information Engineering采用Crow's Foot表示法（也有叫做James Martin表示法的），中文翻译中对使用了Crow's Foot表示法的模型也有笼统的称做鸭掌模型的（关联关系的关联基数中采用到了一个鸭掌形的三叉线来表示）。他由Clive Finkelstein发明，与James Martin一起推广，后来两人各自做了些修正形成两份版本
前面示例模型的Information Engineering表示如下：

图：Information Engineering - IE模型 - Crow's Foot Model - 鸭掌模型图：Information Engineering - IE模型

    注意IE模型与ER模型的区别。Purchase Order与Party是多对一 n:1 的关联关系，在ER模型中n被放置在了Party的左边，而IE模型中n被放置在了Purchase Order的右边。两种表示法的形式（相当于语法）不一样，但语义是一致的。这一点也只有ER模型是特殊的，其他模型表示法中都与IE 模型一致

Entity & Attribute：实体属性并不出现在IE模型中，而是单独使用另外的文档记录
Relationship
Crow's Foot的可选项optionality和关联基数cardinality 表示法：

图：Crow's Foot的可选项optionality和关联基数cardinality 表示法图：Crow's Foot的可选项optionality和关联基数cardinality 表示法

Optionality 可选项：用来表示该关联关系是可选的，还是必须的。对于可选的关联关系，通常表现为用于关联的外键字段允许为null值，或者对于使用中间关联关系表的情况下可以不出现关联数据，而必须的关联关系则不允许外键为null或者必须存在关联数据
Cardinality 关联基数：用来表示关联实体的数量上限，为1、n等
图中右边部分表示的意义如下：1个A必须关联到1个或多个B，一个B可以关联0个或1个A

关联的约束如图所示，Product和Service通过一个圆连接到Order Line。如果是实心圆则表示Product和Service是exclusive or；如果是空心圆则表示Product和Service是inclusive or（相容的，conjunctive），表示可以是其中之一或者多个
在上面IE模型图中，Order Line右侧是Finkelstein的一个特殊符号，表示一个Purchase Order初始时有0或n个Order Line，但最终必须有1或n个Order Line
Martin以动词命名关联关系，只命名一个方向（遵循从左到右、从上往下的方式），而Finkelstein不对关联关系命名

Sub-type：图中Party子类的表示方法由Martin采用，Finkelstein则对每个子类使用单独的实体，使用ISA关联关系（关联关系名称为ISA，也有采用类似UML继承的三角形符合，在关联线上使用一个三角形的）表示其为子类

Richard Barker's Notation
这个表示法最早是英国咨询公司CACI发明，经过了Richard Barker的推广，后来Richard Barker去了Oracle，开发了相关的建模工具，因此也叫做Oracle表示法（Oracle's Notation）
示例模型的Barker表示法如下：

Richard Barker's Model图：Richard Barker模型

Entity & Attribute：实体试用圆角的方框表示，属性出现在实体框中。可选属性（允许null）前面带一个空心圆，必须的属性（不允许null）前面带一个实心圆，唯一标识属性前面带一个#符号（因为制图工具原因，有时可选属性前面不使用任何符号，必须属性前使用一个点）

Relationship：
Barker表示法中可选项通过半边连接线的虚实线表示，表示法如下图所示。上面的模型中Purchase Order必须关联到一个Party，所以关联线在Party一侧的那一半是实线表示；而Party可以关联到0或多个Purchase Order，所以关联线在Purchase Order一侧的那一半是虚线表示

图：Richard Barker's Notation图：Richard Barker's Notation

关联基数为n时采用一个三叉线，线条末端没有符号时表示关联基数为1
另外Barker表示法中有一个表示aggregation、composition的特殊符号，例如示例模型中的Purchase Order和Order Line的关系，在Order Line右侧的三叉线边上添加一个竖线，注意与Crow's Foot表示法之间的区别
Sub-type：Barker表示法中子类型显示在父类型的实体框中
Constraint：Barker表示法仅支持exclusive or约束，如示例模型中所示，用一条弧线划过2个关联关系

IDEF1X模型
IDEF1X是美国联邦政府广泛使用的一种模型，前面示例模型的IDEF1X等效模型如下：

图：IDEF1X模型图：IDEF1X模型

Entity & Attribute：实体使用方框和圆角框表示，独立实体（Independent entities，主键不包含其他实体主键值）使用方框，非独立实体（dependent entities，主键包含其他实体主键值）使用圆角框。属性出现在实体框中，主键用线隔开

Relationship：
外键不是使用关联线表示，必须在实体属性中明确的标注外键属性
如果关联关系一方的唯一标识将作为另一方唯一标识的一部分（即identifying relationship），关联线使用实线，否则（即non-identifying relationship）使用虚线

不同于IE模型，IDEF1X中可选项和关联基数是分开表示的，关联线的一端表示关联基数，另一端表示可选项

图：IDEF1X Cardinality 关联基数图示图：IDEF1X Cardinality 关联基数图示
如IDEF1X示例模型中，关联基数的图示都是出现在关联关系的左端或者上面，可选项出现在右端或者下面。对于可选的关联关系（即类似外键允许为null 值的情况），在可选项一端使用一个菱形，例如示例模型中Event Category左边的菱形；对于必须的关联关系（即外键必须为有效的实体标识值的情况），则在可选项一端直接将关联线与实体连接。对于多对多的情况，两端均使用关联基数符号，可选项问题在模型中通过其他文档标注

关联关系的名称有几种表示方法。默认情况下遵循从左至右从上至下的顺序，关联关系从左至右的名称放在关联线上方，从右至左的名称放在关联线下方。也可以使用一个反斜杠将两个方向的名称分开，从左至右从上至下的在反斜杠前面，否则在后面

Sub-type & Constraint
IDEF1X中的子类和关联约束分别如示例模型中所示。另外一点，示例模型中的子类和关联约束图例中，小圆圈下面都是使用2条横线，这表示模型中已经列举了所有的子类和约束情况，如果模型只是部分列举子类和约束情况，则使用1条横线
Domain：IDEF1X中定义了domain，domain即数据类型的定义，比如数据类型、取值范围等各种需要运用到属性值上的约束
详尽的IDEF1X规范参考IDEF1X标准：Integration Definition for Information Modeling

EXPRESS-G表示法
EXPRESS-G是一个ISO标准ISO 10303-11。示例模型的EXPRESS-G表示法如下（省略了Event、Event Category部分）：

图：EXPRESS-G表示法图：EXPRESS-G表示法

Entity & Attribute：
实体使用方框表示，实体名称出现在方框中
属性通过空心圆结束的线条连接到属性值类型，属性名称出现在线条上。可选属性使用虚线条连接，必须属性使用实现连接
属性值类型使用右边多一条竖线的方框表示，ISO规范中确定的简单数据类型（String, Binary, Logical, Boolean, Number, Integer, Real等）均使用上图中所示的实体框表示。扩展或者自定义的数据类型使用虚线框表示，例如上图示例中order_date属性的DATE类型。枚举类型的表示方法如下图：

图：EXPRESS-G的枚举表示方法图：EXPRESS-G的枚举表示方法

Relationship：
使用空心圆结束的线条连接关联实体
关联关系的名称出现在关联线上，朝空心圆一端的方向为正向，相反则为反向，反向的关联关系名称前面使用(INV)表示
关联基数紧随关联名称之后，第一个字符可以是S、B、L、A，分别表示Set、Bag、List、Array，后面中括号的内容即为关联基数，问号表示多个。默认情况下（没有明确标注）关联基数都为[1:1]，因此上图中出现[1:1]的地方都可以省略

前面提到过的exclusive or约束，EXPRESS-G中使用Select（可选类型）表示，如上图中的order_line_item

Sub-type：如上图中Party、Person、Organization所示，连接线使用粗线条

ORM - Object-Role Modeling
下面是ORM2的部分表示法
基本元素
下面是ORM模型几个基本元素图示：

图：ORM模型基本元素图：ORM模型基本元素

唯一性约束表示法
ORM中唯一性约束是在相应角色上使用带箭头的线条表示，线条在哪些角色上，则这些角色的组合必须唯一，例如下图：

图：ORM模型唯一性约束表示法图：ORM模型唯一性约束表示法
图中Person is of Gender的关系中，Person必须唯一，因此这是一个n:1的关系。同样Person was born in Country是1:n，Person speaks Language是n:m，Person is president of Country是1:1

下面表格是用于理解Person is of Gender、Person was born in Country的数据示例：

图：数据示例

关联关系中必须的角色使用带圆点的线条表示，如上图中Person was born in Country
上面示例中的唯一性约束都是位于一个关联关系（包括二元和多元关系）中，这种唯一约束叫做内部唯一约束Internal UC。多个关联关系组合起来形成的唯一约束称为外部唯一约束External UC，例如下图所示

图：ORM模型External UC图：ORM模型External UC
图中State具有2个外部唯一约束，一个是Country+StateCode，圆圈中使用2跟线条表示这个唯一约束作为State的主键；另一个是 Country+StateName

Inclusive or ((disjunctive mandatory role)

图：ORM Inclusive or表示每个Visitor必须有护照Passport或者驾驶执照DriverLicence，或者两样都有

Exclusive

图：ORM Exclusive约束表示Person不可能同时是married和widowed状态

exclusive or则是inclusive or和exclusive的结合，即必须是其中之一

图：ORM Exclusive or约束

详细的ORM2图形表示法参考ORM 2 Graphical Notation Summary
使用ORM建模的过程示例参考Object Role Modeling: An Overview
ORM2的完整介绍参考ORM2

参考
Wiki - Entity-relationship model
Wiki - IDEF1X
Data Modeling 101
Wiki - EXPRESS (data modeling language)
Information modelling - Getting started with EXPRESS-G
Wiki - Object-Role Modeling
Object Role Modeling
A Comparison of Data Modeling Techniques

本文链接

计划清单

2010-09-13T01:45:00Z

备案不是一般的麻烦，个人博客上线暂缓
确定重点关注的领域为：数据库、编译原理、伸缩性架构，以及看完Windows Internals 5th Edition
数据库方面到此为止了，接下来是Antlr

计划清单：
1. 数据库
   对关系数据库理论以及事物并发控制和恢复理论进行了一定了解，数据库方面到此为止。以后如果再有计划应该考虑看看MySQL源码了。Finished: 2010-09-13
2. 编译原理
    a). 研究NHibernate HQL解析机制
    b). 看完《The Definitive Antlr Reference》 - Finished: 2010-12-13
    c). 看完龙书的后面部分
    d). 研究一个完整的编译器，候选：Firefox的JS、SSCLI
3. 伸缩性架构
4. Windows Internals 5th Edition

本文链接

声明：本博客停止更新维护

2010-08-26T02:37:00Z

因为：
1. 博客园内容的组织方式无法满足自己的要求；
2. 系统速度经常很慢；
3. 鱼龙混杂太吵太闹，新文章中有价值的越来越少，无谓的争吵讨论越来越多
所以自己花时间写了个博客系统，以后本博客停止任何更新维护。本以为我的地盘我做主，可以更好的管理自己的内容，但内容的组织确实是个麻烦事，blog、wiki、bbs、twiter等各种方式都无法达到理想的状况，只能说目前的web技术对内容组织呈现还是太过局限了。

目前博客系统的主要功能已经好了，剩下的事情包括功能的完善、博客园文章内容的导入，以及个人网站的空间购买、备案等，估计2、3个月后会开通个人网站。
系统预览：

本文链接

ANTLR SQL解析器代码

2010-05-23T05:37:00Z

博客里有一篇文章ANTLR实现的SQL解析器 - OQL，大概描述了一下用antlr实现的一个简单的sql解析器
有不少人对antlr感兴趣，希望提供这个项目的源代码作为参考，一直没有放出来，原因有以下几个方面：

1. antlr版本问题。
开发时使用的antlr版本不久之后就更新了，与之前的老版本（包括项目中使用的）不兼容，项目中的语法文件已经无法在目前的antlr版本下使用
这次上传的项目中包括当时使用的antlr runtime dll文件（应该是3.0.1版本吧），代码中有生成好的lexer和parser cs文件。但如果要从.g语法文件重新生成lexer和parser，得使用相应的antlr java package，我这边已经没有了，可以看看antlr网站是否还提供下载

2. 实现上很乱。
这是创业的几年里为做项目而写的，这个东西的开发本身不在项目计划之内，因此从了解antlr到这部分代码只用了一个星期的时间赶出来，后来也只是稍微改改bug，没有结构性的调整过，因此实在不具备什么参考作用
主要思路倒是非常简单，用antlr生成AST，然后用visitor模式遍历AST生成sql，visitor的接口也是为了便于实现ORM映射而设计的。但是因为时间仓促，对antlr也没有深入了解，代码实现和语法文件都只能用一个字形容：乱。原来打算好好研究一下antlr，把这个项目也整理一下，不过一直懒的动
前2个星期看nhibernate的HQL解析，他的结构就好多了，建议真正想了解用antlr做sql解析器的，可以好好参考一下nhibernate或者hibernate

因为经常有人发消息留言希望学习一下，请在这里下载：ANTLR SQL解析器代码
说明：
1. 输出类型设置成了windows application形式，里面有个form用来测试解析效果
2. 只支持标准的select查询语句

本文链接

Hibernate Shards 数据的水平、垂直切割（三）- Hibernate Shards结构

2010-04-14T02:41:00Z

主要处理方式
hibernate shards的主要工作方式如下图:

他在hibernate的基础上实现了一层数据切分的处理逻辑。不需要切分的数据直接使用hibernate的SessionFactory和Session进行操作；需要切分的数据，则使用hibernate shards的ShardedSessionFactory和ShardedSession进行操作
hibernate shards的主要任务:
1. 对shards配置的处理
2. 提供一个可扩展的sharding机制，能方便的运用各种sharding策略以及resharding支持等要求
3. 根据配置和sharding机制正确的存取数据

   shards的配置主要包含每个shard对应的数据库连接信息，以及定义一个shard id
   为了充分实现伸缩性以及简化业务逻辑的开发，sharding策略应当以实体id为基础，这样在类似hibernate Session这样的数据操作接口上实现 sharding处理会比较容易，对业务逻辑代码的开发也能比较透明
   上图中get, update, delete等操作都可以取到实体id，然后根据sharding策略的算法计算出shard id，从对应的数据库中执行这些操作。hibernate shards中与这一操作相关的接口是ShardResolutionStrategy
   sharding环境下的save操作涉及到id的生成机制，以及将数据按照sharding策略insert到正确的shard中。hibernate shards中与这一操作相关的接口是ShardSelectionStrategy
   query操作通过hql、Criteria等方式查询结果集，这些查询有可能需要在某个shard或某几shards中进行，也可能需要在全部的shards中进行，与具体业务相关。hibernate shards中与这一操作相关的接口是ShardAccessStrategy
   在resharding的支持方面，hibernate shards实现了virtual shards
   在resharding时主要任务有2个，其一是对sharding算法、配置的修改，其二是对已有数据的重分区处理。如果最开始进行sharding设计时考虑不够完整，resharding时可能会很麻烦。 virtual shards方式在于在一开始就考虑到后续的resharding需求，估算出最大需要的shards数量，以估算出的这个数量配置虚拟shard，然后将虚拟shard映射到当前的实际shard中
   比如对某个数据，目前使用2个shard就足够了，但考虑到后续的业务增长，设置100个虚拟shard，sharding算法均以这100个虚拟shard为基础，然后将虚拟shard 50个一组映射到当前使用的实际shard上。这样在后续需要resharding时，只需要对数据重分区以及修改虚拟shard和实际shard的映射配置就可以，风险比较小

Configuration的处理
configuration部分类图如下:

从前面一篇Hibernate Shards 数据的水平、垂直切割（二）- Hibernate Shards基本演示已经看到了加载配置文件以及创建ShardedSessionFactory的过程

ShardConfiguration用来表示每个shard特有的配置信息，包括：
hibernate.connection.url
hibernate.connection.username
hibernate.connection.password
hibernate.session_factory_name
hibernate.connection.datasource
hibernate.cache.region_prefix
hibernate.connection.shard_id

ShardedConfiguration则持有所有shards对应的ShardConfiguration列表、一个作为原型的Configuration对象以及一个sharding策略的工厂对象ShardStrategyFactory
构造ShardedConfiguration时，他从各个配置文件读取shard配置信息，得到virtual shards与实际shards列表以及之间的映射关系
ShardedConfiguration还具有创建ShardedSessionFactory的职责。在创建ShardedSessionFactory时，hibernate shards循环为每个shard创建一个hibernate的SessionFactory对象，丢给ShardedSessionFactory构造函数
每一个hibernate的SessionFactory对象都是通过原型Configuration来创建的，只是在循环中会将每个shard特有的配置信息（ShardConfiguration的属性）设置到原型Configuration中，再用它来创建SessionFactory对象，这是一种简单的处理方式，避免再去建立额外的配置文件

关键实现
hibernate shards的关键实现部分类图如下:

处理上非常简单，hibernate shards重新实现了hibernate的Session、SessionFactory接口。在前面的configuration处理中，ShardedConfiguration在创建 ShardedSessionFactory时将每个shard对应的hibernate SessionFactory列表传给了ShardedSessionFactory。ShardedSession的主要工作就是调用相关的sharding策略类确定目标shard，使用与他对应的SessionFactory创建hibernate的Session对象，执行操作。对于使用了sharding之后不支持的方法则抛出异常。当然其中会有像query这样特殊的操作（涉及到合并结果集、排序、distinct等一些较麻烦的处理），还要处理一些hibernate lazy loading、detached object等相关的问题，以及其他一些sharding中必须处理的问题，例如cross-shard等
对于hibernate的Criteria、Query等对象，hibernate shards也都实现了Sharded***的版本，用于支持针对shard的query操作

Shards Strategy
shards策略的类图:

ShardSelectionStrategy: 为新增的实体选择shard id，用于save操作的场景，接口方法中传入要执行操作的实体对象
ShardResolutionStrategy: 根据实体类名和id计算出与其对应的shard id，一般用于get、load、update、delete等操的场景，接口方法中会传入实体类名和实体id
ShardAccessStrategy: 主要用于hql、Criteria等查询情况，因其设计机制以及需要处理的事情方面存在些共同性，因此所有的get方法最终也通过ShardAccessStrategy来加载数据。他只是循环为每个目标shard调用ShardOperation<T>的execute方法，把结果丢给ExitStrategy<T>处理。get操作时目标shard是一个明确的shard（通过ShardResolutionStrategy得到），而query操作时则是全部的shard列表（可以通过自定义的ShardAccessStrategy改变）
   hibernate shards提供了2个ShardAccessStrategy的实现:
   SequentialShardAccessStrategy: 逐个shard顺序执行，由ExitStrategy<T>决定是否结束执行过程以及如何处理结果集
   ParallelShardAccessStrategy: 并行的在各个shard执行查询操作，由ExitStrategy<T>决定如何处理结果集
   ShardAccessStrategy加载数据时用到了下面一些接口:
   ShardOperation<T>: 这个是在每个shard上真正执行get或者query动作的接口，get和query操作时通过匿名类实现这个接口
   ExitStrategy<T>: 这个接口的职责是解决如何处理结果集的问题，以及在SequentialShardAccessStrategy这样的场景下是否该结束对后续shard的执行
        对每个shard执行完读取操作后调用该接口的方法addResult，把执行结果丢给他；整个执行结束后调用该接口的compileResults方法处理结果集，并返回给调用者
        FirstNonNullResultExitStrategy: 查询到对象即返回，用于get的情况
        ConcatenateListsExitStrategy: 语义上是合并结果集，返回给调用者，用于hql和Criteria查询。他使用ExitOperationsCollector来完成这一任务
   ExitOperationsCollector: 处理如何合并结果集的逻辑。目前对于hql查询均使用ExitOperationsQueryCollector，他把从各个shard执行的结果集合并返回给调用者；对于criteria查询使用ExitOperationsCriteriaCollector，他在处理结果集时使用另一接口ExitOperation的实现，来处理count、sum、distinct等操作。目前hibernate shards没有对hql进行解析，因此hql中的count、sum、distinct等这样的操作还无法支持

限制
1. 还有很多hibernate的API没有实现
2. 不支持cross-shard的对象关系，比如A、B之间存在关联关系，而A、B位于不同的shard中。hibernate shards提供了CrossShardRelationshipDetectingInterceptor，以hibernate Interceptor的方式来检测cross-shard的对象关系问题，但这个拦截器有一定的开销（比如需要查映射的元数据、有可能过早的触发延迟加载行为等），可以用于测试环境来检测cross-shard关系的问题
3. hibernate shards本身不支持分布式事务，若要使用分布式事务需要采用其他解决方案
4. hql、criteria存在不少限制，相比于hql，criteria支持的特性更多一些
5. Session或者SessionFactory上面有状态的拦截器，在shard环境下面会存在一些问题。拿session来说，在hibernate中拦截器是对单个session上的多次sql执行事件进行拦截，而在shard情况下hibernate shards的ShardedSession会对应每个shard建立一个session，这时拦截器就是跨多个session了，因此hibernate shards要求有状态的拦截器必须通过实现StatefulInterceptorFactory来提供新的实例。如果拦截器需要使用到目标shard的session，则必须实现hibernate shards的RequiresSession接口

本文链接

Hibernate Shards 数据的水平、垂直切割（二）- Hibernate Shards基本演示

2010-04-10T15:53:00Z

准备
1. 以Hibernate Shards 数据的水平、垂直切割（一）- Hibernate测试环境的项目为基础
2. Hibernate Shards使用了commons logging，下载个项目最新的release版本。这里用的版本为1.1.1
3. 在Hibernate Shards 数据的水平、垂直切割（一）- Hibernate测试环境中，我们在mysql中建立了一个hbshards数据库，为了测试shards再建立一个hbshards2的数据库，contact表的结构一样
4. 将Hibernate Shards发布包中的hibernate-shards.jar放到lib目录
    项目引用添加hibernate-shards.jar
    将commons logging发布包中的commons-logging-1.1.1.jar放到lib目录
    CLASSPATH中添加hibernate-shards.jar、commons-logging-1.1.1.jar

Hibernate Shards测试项目
出于结构上的简单考虑，定义一个ShardableEntity的接口，让ContactEntity实现这个接口:

public interface ShardableEntity {
    public String getIdentifier();
}
public class ContactEntity implements ShardableEntity {
    public String getIdentifier(){
        return this._id;
    }
    //other code omitted is the same with previous post
}

映射文件ContactEntity.hbm.xml与上一篇文章中的一样
因为我们需要将contact的数据以切片的形式存入2个数据库中，因此需要配置这2个数据库的信息。Hibernate Shards通过定义2个hibernate的配置文件解决这个问题:
shard0.hibernate.cfg.xml:

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC 
    "-//Hibernate/Hibernate Configuration DTD//EN" 
    "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
      <property name="connection.driver_class">com.mysql.jdbc.Driver</property>
      <property name="connection.url">jdbc:mysql://localhost/hbshards</property>
      <property name="connection.username">root</property>
      <property name="connection.password">dev</property>
      <property name="connection.pool_size">10</property>
      <property name="show_sql">true</property>
      <property name="dialect">org.hibernate.dialect.MySQLInnoDBDialect</property>
      <property name="hbm2ddl.auto">validate</property>
      <property name="hibernate.connection.shard_id">0</property>
      <property name="hibernate.shard.enable_cross_shard_relationship_checks">false</property>
      <mapping resource="ContactEntity.hbm.xml" />
</session-factory>
</hibernate-configuration>

shard1.hibernate.cfg.xml:

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC 
    "-//Hibernate/Hibernate Configuration DTD//EN" 
    "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
      <property name="connection.driver_class">com.mysql.jdbc.Driver</property>
      <property name="connection.url">jdbc:mysql://localhost/hbshards2</property>
      <property name="connection.username">root</property>
      <property name="connection.password">dev</property>
      <property name="dialect">org.hibernate.dialect.MySQLInnoDBDialect</property>
      <property name="hibernate.connection.shard_id">1</property>
      <property name="hibernate.shard.enable_cross_shard_relationship_checks">false</property>
</session-factory>
</hibernate-configuration>

其中shard0.hibernate.cfg.xml作为主要的配置文件，针对每个shard创建的SessionFactory对象，除了数据库连接信息的配置之外，都来自shard0.hibernate.cfg.xml
针对其他每个shard创建的SessionFactory，数据库连接信息从相应的配置文件（例如shard1.hibernate.cfg.xml）中读取，读取的内容包括connection.url、connection.username、connection.password、connection.datasource。为了hibernate加载其他shard的配置文件时不抛异常，在其他shard的配置文件中我们还是把必要的配置属性写上去了
hibernate.connection.shard_id属性为每个shard定义一个id，必须有一个shard_id为0的shard，其他的shard_id可以定义为任意整数

我们假定contact的id都是由数字组成的一个8位长度的字符串
对contact的切割策略简单定义为: contact id第一个字符为0-4的存入shard0中，为5-9的存入shard1中
为了实现这一策略，我们需要实现hibernate shards的2个接口
ShardResolutionStrategy接口的实现:

import java.util.List;
import java.util.ArrayList;
import org.hibernate.shards.strategy.resolution.ShardResolutionStrategy;
import org.hibernate.shards.strategy.selection.ShardResolutionStrategyData;
import org.hibernate.shards.ShardId;
/*
 * a simple ShardResolutionStrategy implementation for our ContactEntity
 */
public class MyShardResolutionStrategy implements ShardResolutionStrategy {
    private List<ShardId> _shardIds;
    public MyShardResolutionStrategy(List<ShardId> shardIds){
        this._shardIds = shardIds;
    }
    public List selectShardIdsFromShardResolutionStrategyData(
            ShardResolutionStrategyData arg0){
        List ids = new ArrayList();
        String id = (String)arg0.getId();
        if(id==null || id.isEmpty()) ids.add(this._shardIds.get(0));
        else{
            //our shard selection is identified by the 
            //first char(number) in contact id
            //0-4 => shards0, 5-9 => shards1
            Integer i = new Integer(id.substring(0, 1));
            ids.add(this._shardIds.get(i/5));
        }
        return ids;
    }
}

ShardSelectionStrategy接口的实现:

import java.util.List;
import org.hibernate.shards.ShardId;
import org.hibernate.shards.strategy.selection.ShardSelectionStrategy;
/*
 * a simple ShardSelectionStrategy implementation for our ContactEntity
 */
public class MyShardSelectionStrategy implements ShardSelectionStrategy {
       private List<ShardId> _shardIds;
       public MyShardSelectionStrategy(List<ShardId> shardIds){
           this._shardIds=shardIds;
       }
       public ShardId selectShardIdForNewObject(Object obj) {
           if(obj instanceof ShardableEntity) {
               String id = ((ShardableEntity)obj).getIdentifier();
               if(id==null || id.isEmpty()) return this._shardIds.get(0);
               Integer i = new Integer(id.substring(0, 1));
               //our shard selection is identified by the 
               //first char(number) in contact id
               //0-4 => shards0, 5-9 => shards1
               return this._shardIds.get(i/5);
           }
           //for non-shardable entities we just use shard0
           return this._shardIds.get(0);
    }
}

接下来就是怎么使用hibernate shards的测试代码了:

import java.util.Iterator;
import java.util.List;
import java.util.ArrayList;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.Configuration;
import org.hibernate.shards.*;
import org.hibernate.shards.cfg.*;
import org.hibernate.shards.strategy.*;
import org.hibernate.shards.strategy.access.*;
import org.hibernate.shards.strategy.resolution.*;
import org.hibernate.shards.strategy.selection.*;


public class Main {
    public static void main(String[] args) {
        HibernateShardsTest(args);
    }
    private static SessionFactory createSessionFactory() {
        //加载主配置文件，为每个shard创建SessionFactory对象时将
        //以他作为原型
        Configuration prototypeCfg = new Configuration()
            .configure("shard0.hibernate.cfg.xml");
        //每个shard的配置文件
        List<ShardConfiguration> shardCfgs = new ArrayList<ShardConfiguration>();
        shardCfgs.add(buildShardConfig("shard0.hibernate.cfg.xml"));
        shardCfgs.add(buildShardConfig("shard1.hibernate.cfg.xml"));
        //数据切片策略的工厂对象
        ShardStrategyFactory strategyFactory = buildShardStrategyFactory();
        ShardedConfiguration shardedConfig = new ShardedConfiguration(
            prototypeCfg, shardCfgs, strategyFactory);
        //返回一个ShardedSessionFactory对象
       return shardedConfig.buildShardedSessionFactory();
   }
    private static ShardStrategyFactory buildShardStrategyFactory() {
       ShardStrategyFactory factory = new ShardStrategyFactory() {
           //测试用的自定义数据切片策略的工厂类
           public ShardStrategy newShardStrategy(List<ShardId> shardIds) {
               ShardSelectionStrategy ss = new MyShardSelectionStrategy(shardIds);
               ShardResolutionStrategy rs = new MyShardResolutionStrategy(shardIds);
               ShardAccessStrategy as = new SequentialShardAccessStrategy();
               return new ShardStrategyImpl(ss, rs, as);
           }
       };
       return factory;
    }
    private static ShardConfiguration buildShardConfig(String configFile) {
        Configuration config = new Configuration().configure(configFile);
        return new ConfigurationToShardConfigurationAdapter(config);
    }
    private static void HibernateShardsTest(String[] args){
        String loginId = "RicCC@cnblogs.com";
        String password = "123";
        if(args!=null && args.length==2){
            loginId = args[0];
            password = args[1];
        }
        SessionFactory factory = null;
        try{
            factory = createSessionFactory();
            ShardsTestCreate(factory);
            ShardsTestLogin(factory, loginId, password);
            ShardsTestDelete(factory);
        }catch(Exception e){
            System.out.println(e.getMessage());
            e.printStackTrace();
        }finally{
            if(factory!=null) factory.close();
        }
    }
    private static void ShardsTestCreate(SessionFactory factory){
        Session session = null;
        Transaction transaction = null;
        System.out.println("===Create Contacts===");
        try{
            session = factory.openSession();
            transaction = session.beginTransaction();            
            session.save(new ContactEntity("01111111","RicCC@cnblogs.com"
                    , "123", "Richie", "RicCC@cnblogs.com"));
            session.save(new ContactEntity("91111111","a@cnblogs.com"
                    , "123", "AAA", "a@cnblogs.com"));
            session.save(new ContactEntity("81111111","b@cnblogs.com"
                    , "123", "BBB", "b@cnblogs.com"));
            session.save(new ContactEntity("31111111","c@cnblogs.com"
                    , "123", "CCC", "c@cnblogs.com"));
            transaction.commit();
        }catch(Exception e){
            if(transaction!=null) transaction.rollback();
            System.out.println(e.getMessage());
            e.printStackTrace();
        }finally{
            if(session!=null) session.close();
        }
    }
    private static void ShardsTestLogin(SessionFactory factory
            , String loginId, String password){
        Session session = null;
        ContactEntity c = null;
        System.out.println("\n===Login Test===");
        try{
            session = factory.openSession();
            List contacts = session.createQuery("from ContactEntity where LoginId=:loginId")
                .setString("loginId", loginId)
                .list();
            if(contacts.isEmpty())
                System.out.println("Contact \"" + loginId + "\" not found!");
            else{
                c = (ContactEntity)contacts.get(0);
                if(c.getPassword().equals(password))
                    System.out.println("Contact \"" + loginId + "\" login successful");
                else 
                    System.out.println("Password is incorrect (should be: "
                        + c.getPassword() + ", but is: " + password + ")");
            }
            System.out.println("\n===Get Contact by Id===");
            c = (ContactEntity)session.get(ContactEntity.class, "81111111");
            System.out.println(c.toString());
            c = (ContactEntity)session.get(ContactEntity.class, "31111111");
            System.out.println(c.toString());
        }catch(Exception e){
            System.out.println(e.getMessage());
            e.printStackTrace();
        }finally{
            if(session!=null) session.close();
        }
    }
    private static void ShardsTestDelete(SessionFactory factory){
        Session session = null;
        Transaction transaction = null;
        System.out.println("\n===Delete Contacts===");
        try{
            session = factory.openSession();
            transaction = session.beginTransaction();
            List contacts = session.createQuery("from ContactEntity").list();
            Iterator it = contacts.iterator();
            while(it.hasNext()){
                session.delete(it.next());
            }
            transaction.commit();
        }catch(Exception e){
            if(transaction!=null) transaction.rollback();
            System.out.println(e.getMessage());
            e.printStackTrace();
        }finally{
            if(session!=null) session.close();
        }
    }
}

项目结构图:


运行测试
用Eclipse编译class文件，将生成的所有class文件以及相关的配置、映射文件拷贝到lib目录中，运行Main.class结果如下:
D:\Work\research\Java\Hibernate-Test\lib>java Main
===Create Contacts===
Hibernate: insert into CONTACT (EMAIL, NAME, LOGIN_ID, PASSWORD, ID) values (?,?, ?, ?, ?)
Hibernate: insert into CONTACT (EMAIL, NAME, LOGIN_ID, PASSWORD, ID) values (?,?, ?, ?, ?)
Hibernate: insert into CONTACT (EMAIL, NAME, LOGIN_ID, PASSWORD, ID) values (?,?, ?, ?, ?)
Hibernate: insert into CONTACT (EMAIL, NAME, LOGIN_ID, PASSWORD, ID) values (?,?, ?, ?, ?)

===Login Test===
Hibernate: select contactent0_.ID as ID0_, contactent0_.EMAIL as EMAIL0_, contactent0_.NAME as NAME0_, contactent0_.LOGIN_ID as LOGIN4_0_, contactent0_.PASSWORD as PASSWORD0_ from CONTACT contactent0_ where contactent0_.LOGIN_ID=?
Hibernate: select contactent0_.ID as ID0_, contactent0_.EMAIL as EMAIL0_, contactent0_.NAME as NAME0_, contactent0_.LOGIN_ID as LOGIN4_0_, contactent0_.PASSWORD as PASSWORD0_ from CONTACT contactent0_ where contactent0_.LOGIN_ID=?
Contact "RicCC@cnblogs.com" login successful

===Get Contact by Id===
Hibernate: select contactent0_.ID as ID0_0_, contactent0_.EMAIL as EMAIL0_0_, contactent0_.NAME as NAME0_0_, contactent0_.LOGIN_ID as LOGIN4_0_0_, contactent0_.PASSWORD as PASSWORD0_0_ from CONTACT contactent0_ where contactent0_.ID=?
{ Id="81111111", LoginId="b@cnblogs.com", Name="BBB", EMail="b@cnblogs.com" }
Hibernate: select contactent0_.ID as ID0_0_, contactent0_.EMAIL as EMAIL0_0_, contactent0_.NAME as NAME0_0_, contactent0_.LOGIN_ID as LOGIN4_0_0_, contactent0_.PASSWORD as PASSWORD0_0_ from CONTACT contactent0_ where contactent0_.ID=?
{ Id="31111111", LoginId="c@cnblogs.com", Name="CCC", EMail="c@cnblogs.com" }

===Delete Contacts===
Hibernate: select contactent0_.ID as ID0_, contactent0_.EMAIL as EMAIL0_, contactent0_.NAME as NAME0_, contactent0_.LOGIN_ID as LOGIN4_0_, contactent0_.PASSWORD as PASSWORD0_ from CONTACT contactent0_
Hibernate: select contactent0_.ID as ID0_, contactent0_.EMAIL as EMAIL0_, contactent0_.NAME as NAME0_, contactent0_.LOGIN_ID as LOGIN4_0_, contactent0_.PASSWORD as PASSWORD0_ from CONTACT contactent0_
Hibernate: delete from CONTACT where ID=?
Hibernate: delete from CONTACT where ID=?
Hibernate: delete from CONTACT where ID=?
Hibernate: delete from CONTACT where ID=?

1. 通过id加载实体的时候，hibernate shards使用ShardSelectionStrategy来决定应当从哪个shard加载数据
2. 新增数据的时候，hibernate shards使用ShardResolutionStrategy来决定应当将数据insert到哪个shard中
   这里为什么不能使用ShardSelectionStrategy呢？因为与id的生成机制相关，比如说可以让数据库来生成id（hibernate中的native方式），例如自增id，在shard的应用场景下可以简单的给每个shard一个起止范围，只是在insert数据的时候必须通过特定的算法决定将数据insert到哪个shard中，这样的情况下ShardSelectionStrategy是无法运用的。而对于assigned等类似的id生成机制，还是可以运用ShardSelectionStrategy策略的
3. 执行hql或者Criteria查询的时候，则使用ShardAccessStrategy从shard中查询数据
   上面示例中的buildShardStrategyFactory方法中，我们使用了hibernate shards项目提供的SequentialShardAccessStrategy策略，这个策略在所有shards中逐个执行查询语句，然后对各个结果进行合并

基于上面几点，我们可以对上面测试运行后的输出做出解释了:
两个使用了hql的地方，都产生了两次sql查询，这是因为使用了SequentialShardAccessStrategy缘故，他从我们定义的两个shard中分别执行sql查询，合并结果集返回给调用者

把测试代码中的删除语句注释掉，运行测试后查询数据库，可以确认数据都是正确的insert在相应的shard中的

总结
上面演示了hibernate shards的基本用法，总体来看使用上非常简单，只需要针对实施shard的实体使用hibernate shards提供的ShardedSessionFactory即可
使用hibernate shards也存在一些限制，但大部分都是使用shards后的一些设计要求，或者是目前的it技术背景下对shards设计上的约束，在后面一篇中再详细整理一下这方面内容
文中使用的测试项目源文件在这里: 下载。引用到的jar文件需要从相关项目网站去下载

本文链接

Hibernate Shards 数据的水平、垂直切割（一）- Hibernate测试环境

2010-04-09T14:44:00Z

准备
需要用到的东西如下，下载这几个项目最新的release版本:
1. Hibernate Core，这里用的版本为3.5.0-final
2. Hibernate Shards，这里用的版本为3.0.0-Beta2
3. MySql java connector，这里用的版本为5.1.12
4. slf4j，这里用的版本为1.5.11
5. 安装并启动mysql服务，在mysql中建立数据库hbshards，在里面如下建立测试用的contact表:

CREATE TABLE contact (  
    ID varchar(8) NOT NULL,  
    LOGIN_ID varchar(18) NOT NULL,  
    PASSWORD varchar(12) NOT NULL,  
    NAME varchar(40) NOT NULL,  
    EMAIL varchar(40) NOT NULL,  
    PRIMARY KEY (ID)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

6. 设置好java环境变量
这里用于这个测试的CLASSPATH设置如下
.;
D:\Work\research\Java\Hibernate-Test\lib\antlr-2.7.6.jar;
D:\Work\research\Java\Hibernate-Test\lib\dom4j-1.6.1.jar;
D:\Work\research\Java\Hibernate-Test\lib\jta-1.1.jar;
D:\Work\research\Java\Hibernate-Test\lib\javassist-3.9.0.GA.jar;
D:\Work\research\Java\Hibernate-Test\lib\commons-collections-3.1.jar;
D:\Work\research\Java\Hibernate-Test\lib\slf4j-nop-1.5.11.jar;
D:\Work\research\Java\Hibernate-Test\lib\slf4j-api-1.5.11.jar;
D:\Work\research\Java\Hibernate-Test\lib\mysql-connector-java-5.1.12-bin.jar;
D:\Work\research\Java\Hibernate-Test\lib\hibernate3.jar;

Hibernate测试项目
用Eclipse建一个java项目Hibernate-Test，在项目文件夹下面建立lib目录
将hibernate3.jar放入lib目录中，把Hibernate发布包中lib\required目录下除了slf4j-api-1.5.8.jar之外的其他jar文件放入lib目录中
将mysql java connector发布包中的mysql-connector-java-5.1.12-bin.jar放入lib目录
将slf4j发布包中的slf4j-api-1.5.11.jar、slf4j-nop-1.5.11.jar放入lib目录
项目从lib目录中引用hibernate3.jar

在src目录下添加测试用的实体类ContactEntity:

public class ContactEntity {
    private String _id;
    private String _name;
    private String _email;
    private String _loginId;
    private String _password;


    public ContactEntity(){}
    public ContactEntity(String id, String loginId, String password
            ,String name, String email){
        this._id = id;
        this._loginId = loginId;
        this._password = password;
        this._name = name;
        this._email = email;
    }    
    public String getId(){
        return this._id;
    }
    public void setId(String id){
        this._id=id;
    }
    public String getEMail(){
        return this._email;
    }
    public void setEMail(String email){
        this._email=email;
    }
    public String getName(){
        return this._name;
    }
    public void setName(String name){
        this._name=name;
    }
    public String getLoginId(){
        return this._loginId;
    }
    public void setLoginId(String loginId){
        this._loginId=loginId;
    }
    public String getPassword(){
        return this._password;
    }
    public void setPassword(String password){
        this._password=password;
    }
    public String toString(){
        return "{ Id=\"" + this._id + "\""
            + ", LoginId=\"" + this._loginId + "\""
            + ", Name=\"" + this._name + "\""
            + ", EMail=\"" + this._email + "\" }";
    }
}

测试实体的映射文件ContactEntity.hbm.xml:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC 
    "-//Hibernate/Hibernate Mapping DTD 3.0//EN" 
    "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
    <class name="ContactEntity" table="CONTACT">
        <id name="Id" column="ID" >
            <generator />
        </id>        
        <property name="EMail" column="EMAIL" />
        <property name="Name" column="NAME" />
        <property name="LoginId" column="LOGIN_ID" />
        <property name="Password" column="PASSWORD" />
    </class>
</hibernate-mapping>

测试用的类:

import java.util.Iterator;
import java.util.List;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.Configuration;


public class Main {
    public static void main(String[] args) {
        String loginId = "RicCC@cnblogs.com";
        String password = "123";
        if(args!=null && args.length==2){
            loginId = args[0];
            password = args[1];
        }
        HibernateTest(loginId, password);
    }
    private static void HibernateTest(String loginId, String password){
        SessionFactory factory = null;
        Session session = null;
        Transaction transaction = null;
        List contacts = null;
        Iterator it = null;
        try{
            factory = new Configuration().configure().buildSessionFactory();
            session = factory.openSession();
            transaction = session.beginTransaction();


            System.out.println("===Create Contacts===");            
            ContactEntity c = new ContactEntity("01111111","RicCC@cnblogs.com"
                    , "123", "Richie", "RicCC@cnblogs.com");
            session.save(c);
            c = new ContactEntity("91111111","a@cnblogs.com"
                    , "123", "AAA", "a@cnblogs.com");
            session.save(c);
            c = new ContactEntity("81111111","b@cnblogs.com"
                    , "123", "BBB", "b@cnblogs.com");
            session.save(c);
            c = new ContactEntity("31111111","c@cnblogs.com"
                    , "123", "CCC", "c@cnblogs.com");
            session.save(c);
            session.flush();


            System.out.println("\n===Login Test===");
            contacts = session.createQuery("from ContactEntity where LoginId=:loginId")
                .setString("loginId", loginId)
                .list();
            if(contacts.isEmpty())
                System.out.println("contact " + loginId + " not found!");
            else{
                c = (ContactEntity)contacts.get(0);
                if(c.getPassword()==password)
                    System.out.println("user " + loginId + " login successful");
                else 
                    System.out.println("password is incorrect, login failed!");
            }


            System.out.println("\n===Delete Contacts===");
            contacts = session.createQuery("from ContactEntity").list();
            it = contacts.iterator();
            while(it.hasNext()){
                session.delete(it.next());
            }
            transaction.commit();
        }catch(Exception e){
            if(transaction!=null) transaction.rollback();
            System.out.println(e.getMessage());
        }finally{
            if(session!=null) session.close();
            if(factory!=null) factory.close();
        }
    }
}

Hibernate配置文件hibernate.cfg.xml:

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC 
    "-//Hibernate/Hibernate Configuration DTD//EN" 
    "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
      <property name="connection.driver_class">com.mysql.jdbc.Driver</property>
      <property name="connection.url">jdbc:mysql://localhost/hbshards</property>
      <property name="connection.username">root</property>
      <property name="connection.password">dev</property>
      <property name="connection.pool_size">10</property>
      <property name="show_sql">true</property>
      <property name="dialect">org.hibernate.dialect.MySQLDialect</property>
      <property name="hbm2ddl.auto">validate</property>
      <mapping resource="ContactEntity.hbm.xml" />
</session-factory>
</hibernate-configuration>

项目结构如下图:

运行测试
用Eclipse编译class文件，将Main.class、ContactEntity.class以及hibernate.cfg.xml、ContactEntity.hbm.xml 拷贝到lib目录中，运行Main.class结果如下:

本文链接

博客园_Richie

SQL Server用错关联方式

事务信息系统-并发控制与恢复的理论, 算法与实践-计算模型, 并发控制部分

数据库系统 - 面向应用的方法

Data Modeling Technologies - ER, IE, Barker, IDEF1X, EXPRES-G, ORM

计划清单

声明：***本博客停止更新维护***

ANTLR SQL解析器代码

Hibernate Shards 数据的水平、垂直切割（三）- Hibernate Shards结构

Hibernate Shards 数据的水平、垂直切割（二）- Hibernate Shards基本演示

Hibernate Shards 数据的水平、垂直切割（一）- Hibernate测试环境

声明：本博客停止更新维护