[原创]简单地解释一下应用程序/代理进程和交易之间的关系
可能很多刚刚接触db2的朋友经常被那些莫名其妙的应用程序，代理进程，交易，concentrator，intra-parallel，inter-parallel之类的冬冬弄得头晕脑涨，现在俺来用一个银行取钱的例子解释一下这些都是什么咚咚 ：）=======================================================（这部分介绍应用...显示全部
可能很多刚刚接触db2的朋友经常被那些莫名其妙的应用程序，代理进程，交易，concentrator，intra-parallel，inter-parallel之类的冬冬弄得头晕脑涨，现在俺来用一个银行取钱的例子解释一下这些都是什么咚咚 ：）
=======================================================
（这部分介绍应用程序，代理进程，交易，concentrator，分区内并行，分区间并行，分区数据库等概念）
首先我们来想象一个很古怪的银行，叫做MyBank，其中涉及欧元，美元，人民币和日元的业务。但是什么地方古怪呢，就是它只有四个支行，每个支行负责一种货币业务。也就是美元的支行只负责美元的，人民币支行只负责人民币的。这里，货币的类型就叫做分区键，所有人民币的业务都到人民币支行，所有美金的业务呢都到美元支行拉……
现在用db2的话说，这个古怪的银行就是MyBank数据库……
某一天呢，一个人跑到MyBank的人民币支行，这个人叫做大菠萝好了(^_^)。大菠萝就是所谓的应用程序，跑过来找银行帮忙办事的 ：）
大菠萝要干嘛呢，不存钱不取钱，只是查账，也就是query only的一个应用程序。
大菠萝跑进了银行大厅，首先拿号，这个号就叫做应用程序id，每一个跑到银行来得人都有一个自己的号。如果下次来还要拿号，号码可能不一样滴……
现在我们来看看什么是concentrator。所谓的concentrator就是规定，派发出去的号码是否能够超过当前出纳小姐的数量，这里的出纳小姐就是代理进程^_^，为顾客服务的嘛……
如果银行规定了派发出去的号码的数量不能够超过出纳小姐的数量，也就是说没有打开concentrator，这样可以确保每一个顾客都有至少一个出纳为之服务。
但是如果银行说号码随便发，多来的人排队等着（好像大部分银行那样），这也就是打开了concentrator，进来的连接数目可以超过代理进程的数量。
这个时候大菠萝同学运气不错，很多窗口都是空的，于是大菠萝来到一个窗口前，出纳小姐热情地接待了顾客，问：1234号出纳员为您服务，请先输入您的密码。
这里1234号就是db2代理进程id。
大菠萝自然输入了自己的密码，这个就是authentication部分。
看到密码okay了，出纳小姐问：先生您需要什么服务涅？
大菠萝说：俺要查帐，看看俺还有多少钱。
这个自然就是应用程序发起的query咯……
然后呢，出纳小姐就开始为这个顾客服务拉，动动鼠标打开电脑，输入自己的账号密码，这个就是所谓的一个交易的开始，银行里对所有操作不是都要有记录么，这个记录的号码就是交易id……
这个时候大菠萝拿出一个很长很长的单子，说俺的账号比较多，你们最好帮忙帮忙查一下这张单子上所有账号都有多少钱……看着密密麻麻的号码，出纳小姐脸儿都绿了。
此时呢，如果这个银行允许出纳员之间互相帮忙（intra-parallel分区内并行）呢，这个出纳小姐就可以叫另外一个或者多个空闲的出纳帮忙清点这些单子上的账号，但是如果没有intra-parallel呢，这个可怜的代理进程就只能自己慢慢做了。
这个时候大菠萝又说了，俺不光要看人民币的，还要看看俺美金账户，日元账户，欧元账户里面有多少钱。紧接着又是好几张单子……
出纳小姐苦着脸给另外三家支行打电话，把要看得账户告诉另外的那些支行。这个就是inter-parallel分区间并行，每个支行相当于一个db2分区，而这个电话线就是FCM(fast communication manager)，主要用来管理分区间通讯的模块……
不过当大菠萝想要查其他三种货币的时候，出纳小姐一个人肯定不够用了，于是就拽过来另一个出纳小姐，让那个出纳小姐帮忙查人民币的账号，自己呢忙着打电话，忙着记录下其他几个银行对于每一个账号还有多少钱的回复。于是这个打电话的1234号出纳员就叫做coordinate agent，因为她自己不用真正察看数据，而是在不同的分区间协调调度。而这个新来得出纳小姐与其他三家支行查账的出纳员则是subagent。
这一笔好长好长交易终于完了，出纳小姐松了口气，大菠萝呢还坐在柜台前看自己长长单子，死活不肯离去……
这个银行肯定是资本家开的，剥削员工是他们的本质，所以他们打开了concentrator，也就是说如果当出纳小姐完成一单交易后，不论客户走了没有，只要他当时没有其他请求，出纳小姐就要跑到另外一个窗口服务其他的客户……
可怜的出纳小姐1234于是跑到另外一个窗口，为下一个客户（应用程序）服务了。
过了一会，大菠萝终于看完单子了，不过他老人家先不急着走，而是站起来活动一下筋骨，然后转眼间又坐回去了。
====================================================================================
（这部分介绍分区表，表分区键，MDC，优化器，UOW Waiting，UOW Exeucting等概念）
不多时，跑过来另外一个出纳MM。鉴于刚才1234号的悲惨遭遇，这位MM心虚地问：我是1235号，请问还能为您做点什么么？
大菠萝呢，推了推鼻梁上黑客帝国型的墨镜，咳嗽了一下，又从包包里面掏出一把花花绿绿的纸片。
什么咚咚？只听大菠萝说话了：这些呢是这几年来俺老板买的银行债卷，每年都买的哦~~~俺老板想要兑换出一部分不知道行不行啊
大菠萝的老板何许人？marcozeng是也，那可是金融界赫赫有名的大亨，MyBank银行最大的VIP客户之一哦。
说回那银行债券，自然是按照年份排好的。2001年的债券有自己的一套账本，2002年的也有自己的一套账本，2003年的自然也有自己单独的账本……也就是说，尽管这些信息都是有关债券的，但是物理上他们的信息是根据年份的不同分布在不同的账本上。这一套账本可以被看作债券的分区表，而作为区分不同账本的年份则是表分区键。
这样做有什么好处呢？比如你看现在，大菠萝说，我要把05年的债卷兑现五百万，都要100块一张的面额的；但是从06年的债卷里面要我兑换3000张50块面额的；07年的债券里面兑换5000张20块的现金（难道是要做什么不正当交易？要不拿那么多现金干啥）。这样把债券信息按照年份分类的好处就是可以不用在乎其他年份的，只需要关注05，06，07年三年的数据就可以拉~~~
不过marcozeng作为VIP，银行自然不能跑去问你提那么多现金干啥，只能老老实实照办。但是这么多钱，光装出来就要3大箱子，大菠萝一个人弄不走，怎么办？
大菠萝说了，这些钱先放到俺老板在银行里的保险柜好了，我们明天来取。
由于marcozeng是VIP，每一位VIP在银行里都有一个单独的保险柜。在每个保险柜里面呢，又有好几个小格子可以按照100/50/20/10块的面额把钞票码放整齐。在这里，如果把整个VIP保险库看作一个大的表，那么VIP账号则可以看作一个维度（每一个VIP都有属于自己的一个保险箱），然后这个箱子里面的不同面额类型的小格子可以被看作第二个维度，这样如果在提款的时候说：我要从marcozeng的保险箱里面提出100张50块面额的，银行的出纳小姐可以很快地找到钱在哪里。这个就是所谓MDC（多维群集）的概念，换句话说，就是把一种东西按照多种条件排列整齐（VIP姓名与钞票面额），使得查找数据变得更加方便。
不过这个1235出纳MM好像是新来得，不知道银行里那么多讲究，也不清楚该从何入手去查那些债券信息，于是跑去问主管。
主管一听就乐了，说你把那些账本拿出来，只用看2005，2006，2007年的就够了，然后把提出来得钱从上面划了，然后把现金弄出来，按照VIP名字找到他的保险箱，按照面额码放到小格子里面不就好啦。
这个主管就是优化器了，在代理进程不知道怎样访问数据的时候找到一个最有效的方法，告诉代理进程该怎么弄，然后代理进程就会根据指示去完成任务鸟。而这一长串只是就是所谓的访问计划。如果出于什么原因大菠萝同学过一会提出一个同样的要求，1235号出纳MM已经记住了怎么做这种业务了（SQL在package cache里面，不需要再次生成访问计划），就不用跑去问主管，自己按照指示在做一次就好了。
过了好一会，1235号出纳MM才跑出来，说：大哥，钱都给你整理好了，就等你明天来取了。还有啥要帮忙的不？
大菠萝坐在那说话了：你先忙你的去，我再想想还有啥要办的。
于是1235小姐可算脱身了，忙不迭地跑到另外一个窗口去服务下一个客户（stealing agent），大菠萝这个应用程序呢还占着窗口不走（应用程序UOW Waiting），也不办理业务（如果办理业务，在db2里面该应用程序就是UOW Exeucting状态拉），搞得后面好多客户都没有窗口只能排队 （窗口数量就是max connection的设置，出纳小姐的数量就是maxagent，如果窗口被占满了，后面的那些应用程序就连不上数据库咯）。
不知道这位大菠萝同学还需要办理什么业务呢？
===========================================
（这部分介绍事务，锁，死锁，锁等待超时，crash，crash recovery等概念）
不一会，只听大菠萝“哎呀”一声，惹得银行里的众人都转过头来看怎么回事。
旁边一位膀大腰圆的保安虎着脸，指了指墙上贴着的“安静”两个大字。
“差点忘了件重要的事……”大菠萝嘀咕道。
“小姐，俺还要给俺老板的员工发工资，他们的账号和要发的工资数额都在这里。钱从这个帐号扣除……”对着另一位刚刚跑来的1236号出纳MM，大菠萝说道。
说着，大菠萝递过去一个小本子，上面四五十页都密密麻麻地写满了员工的账号和工资……
出纳MM有一股想要吐血的冲动，不过还是忍住了，于是开始从小本子的第一个帐号开始，一点一点地从指定帐号扣钱，然后转入员工的账号。
为了加快速度，出纳MM没有转一笔帐就确认一次，而是转十笔帐才在电脑上点确认按钮一次（事务提交）。
不过就在操作过程中，出纳MM突然“咦”了一声：“好像这个员工帐号现在有人在查询，我需要等他查完了才能转帐，要不然他看到的结果可能就不正确拉。（锁等待，互斥锁等待共享锁）”MM指着小本子里面的一条记录说道。（因为数据修改后，在提交之前，我们并不能保证用户在未来是会真的提交还是会撤消交易--回滚--所以在修改时会请求一个互斥锁，也就是说当时不能有别的交易访问这条记录。而共享锁的意思就是说可以有很多人同时看这条记录，但是不能有别人修改）
大菠萝左右扭扭头，确实发现几个公司中熟悉的面孔出现在MyBank银行里。
就这样，大菠萝和出纳MM就在那里大眼瞪小眼地等着。不多时，柜台值班经理巡视的时候跑过来问：“哎，你们那几个出纳员，怎么闲着不干活啊？”
1236号出纳MM指着不远处的一个同样闲着等什么的出纳MM说：“我在等她确认查账完成阿（等待另一个应用的提交）”。
值班经理又问那个MM：“那你呢？”
另一个MM委屈地指着1236号出纳说：“我在等她确认修改记录的提交啊……”
“怎么回事？”值班经理纳闷了，怎么两个MM互相等啊？
原来另外这个出纳MM查账的时候不是查一个账户，而是夫妻两个人的账户，而恰好这对夫妻都在marcozeng手下的同一个公司上班，而更巧1236号出纳MM已经修改了老婆的数据，但是还没有修改老公的数据，而且也没有提交；但是另一个出纳MM是查完老公的账号后没有提交就跑去查老婆的账号……这样一来，察看老婆账号的请求首先要等1236号MM提交记录，因为1236号MM已经修改了数据了。但是1236号MM同时也在等这个出纳MM确认交易，因为查找老公的账号完成后还没有提交，这就出现了两边互相等待的情况，也就是出现死锁拉。
用时间图表示就是
出纳1236 -------修改老婆账号----------------------修改老公账号 （等待0000）
出纳0000 --------------察看老公账号------------------------------察看老婆账号（等待1236）
经理一看这样怎么办啊，于是就随便指了指两个出纳MM的其中一个，说你把你刚才的交易撤销，然后重新做一遍吧（值班经理就是死锁监测器db2dlock进程，而巡视一趟的时间就是DLCHKTIME参数定义）。
于是另外那个出纳MM一脸不高兴地回去撤销自己的交易了。
不过还没两秒钟，只听旁边一个座位上的大叔大喊起来：“你们有没有搞错，我都在这里等了20分钟了，你tmd一直在说别人的交易正在运行，不让我查账……”
话还没说完，左右两个穿着保安制服的彪形大汉就一左一右地把他架起来，拖到银行门口，一脚踹了出去（应用程序锁等待超时，连接中断了……），然后目无表情地指了指墙上“安静”两个大字……
全场的人那叫一个寒的说……
不过这不影响大局，银行依然是井然有序地帮助一个个客户处理业务，而大菠萝的那个小本子也已经翻到最后一页，马上就要完成了……
这个时候，忽然银行里所有的电脑和灯一下子都灭了。“哇，整个小区都停电了……”所有的业务都不转了，没有电脑怎么工作？ （实例崩溃，crash了，小区就是实例，如果小区里面有若干个银行，所有银行都不工作了就……）
半分钟不到，灯又亮了，不过很多人的交易只处理到一半，怎么办？现在暂时自然不能办理客户业务了，首先要把已经确认的交易真正落实下去（比如取款的，可能已经从账户上扣了钱，点了确认按钮，但是还没有把现金给客户（db2中的概念就是脏页还没有刷新到磁盘）），还有的则是要把没有确认的交易撤销掉。比如刚才大菠萝的这个交易，最后７，８个员工的转账还没有点“确认”按钮就停电了，所以银行必须把这个没有确认的交易撤销掉，已经划走的钱要重新弄回来，已经存进去的钱要取出来（回滚）。只有当这些操作都做完了以后（crash recovery完成）银行才能继续恢复对外业务。
折腾了好一会，终于弄得差不多了。于是银行重新开了所有的窗口，排队的人呢则需要重新领号（应用程序重新连接）。
这次还是挺幸运的，大菠萝又领到了一个靠前的号码，很快就排到了一个窗口。里面的出纳MM帮助大菠萝把剩下的几个员工的工资发了，然后大菠萝拍拍包包，说：今天的任务终于完成了，我走了哈，明天来提款……
就这样大菠萝施施然地走出了银行大门（应用程序断开连接），哼着１８摸得小调渐渐地消失在远方……
（鸣谢大菠萝友情客串演出，marcozeng补充内容，同时兼任VIP客户）
大家还有什么其他的概念可以放到这个场景里，欢迎补充哈:) 能弄成故事接龙最好^_^ [ 本帖最后由 wangzhonnew 于 2008-12-11 23:03 编辑 ]收起
=======================================================
（这部分介绍应用程序，代理进程，交易，concentrator，分区内并行，分区间并行，分区数据库等概念）
首先我们来想象一个很古怪的银行，叫做MyBank，其中涉及欧元，美元，人民币和日元的业务。但是什么地方古怪呢，就是它只有四个支行，每个支行负责一种货币业务。也就是美元的支行只负责美元的，人民币支行只负责人民币的。这里，货币的类型就叫做分区键，所有人民币的业务都到人民币支行，所有美金的业务呢都到美元支行拉……
现在用db2的话说，这个古怪的银行就是MyBank数据库……
某一天呢，一个人跑到MyBank的人民币支行，这个人叫做大菠萝好了(^_^)。大菠萝就是所谓的应用程序，跑过来找银行帮忙办事的 ：）
大菠萝要干嘛呢，不存钱不取钱，只是查账，也就是query only的一个应用程序。
大菠萝跑进了银行大厅，首先拿号，这个号就叫做应用程序id，每一个跑到银行来得人都有一个自己的号。如果下次来还要拿号，号码可能不一样滴……
现在我们来看看什么是concentrator。所谓的concentrator就是规定，派发出去的号码是否能够超过当前出纳小姐的数量，这里的出纳小姐就是代理进程^_^，为顾客服务的嘛……
如果银行规定了派发出去的号码的数量不能够超过出纳小姐的数量，也就是说没有打开concentrator，这样可以确保每一个顾客都有至少一个出纳为之服务。
但是如果银行说号码随便发，多来的人排队等着（好像大部分银行那样），这也就是打开了concentrator，进来的连接数目可以超过代理进程的数量。
这个时候大菠萝同学运气不错，很多窗口都是空的，于是大菠萝来到一个窗口前，出纳小姐热情地接待了顾客，问：1234号出纳员为您服务，请先输入您的密码。
这里1234号就是db2代理进程id。
大菠萝自然输入了自己的密码，这个就是authentication部分。
看到密码okay了，出纳小姐问：先生您需要什么服务涅？
大菠萝说：俺要查帐，看看俺还有多少钱。
这个自然就是应用程序发起的query咯……
然后呢，出纳小姐就开始为这个顾客服务拉，动动鼠标打开电脑，输入自己的账号密码，这个就是所谓的一个交易的开始，银行里对所有操作不是都要有记录么，这个记录的号码就是交易id……
这个时候大菠萝拿出一个很长很长的单子，说俺的账号比较多，你们最好帮忙帮忙查一下这张单子上所有账号都有多少钱……看着密密麻麻的号码，出纳小姐脸儿都绿了。
此时呢，如果这个银行允许出纳员之间互相帮忙（intra-parallel分区内并行）呢，这个出纳小姐就可以叫另外一个或者多个空闲的出纳帮忙清点这些单子上的账号，但是如果没有intra-parallel呢，这个可怜的代理进程就只能自己慢慢做了。
这个时候大菠萝又说了，俺不光要看人民币的，还要看看俺美金账户，日元账户，欧元账户里面有多少钱。紧接着又是好几张单子……
出纳小姐苦着脸给另外三家支行打电话，把要看得账户告诉另外的那些支行。这个就是inter-parallel分区间并行，每个支行相当于一个db2分区，而这个电话线就是FCM(fast communication manager)，主要用来管理分区间通讯的模块……
不过当大菠萝想要查其他三种货币的时候，出纳小姐一个人肯定不够用了，于是就拽过来另一个出纳小姐，让那个出纳小姐帮忙查人民币的账号，自己呢忙着打电话，忙着记录下其他几个银行对于每一个账号还有多少钱的回复。于是这个打电话的1234号出纳员就叫做coordinate agent，因为她自己不用真正察看数据，而是在不同的分区间协调调度。而这个新来得出纳小姐与其他三家支行查账的出纳员则是subagent。
这一笔好长好长交易终于完了，出纳小姐松了口气，大菠萝呢还坐在柜台前看自己长长单子，死活不肯离去……
这个银行肯定是资本家开的，剥削员工是他们的本质，所以他们打开了concentrator，也就是说如果当出纳小姐完成一单交易后，不论客户走了没有，只要他当时没有其他请求，出纳小姐就要跑到另外一个窗口服务其他的客户……
可怜的出纳小姐1234于是跑到另外一个窗口，为下一个客户（应用程序）服务了。
过了一会，大菠萝终于看完单子了，不过他老人家先不急着走，而是站起来活动一下筋骨，然后转眼间又坐回去了。
====================================================================================
（这部分介绍分区表，表分区键，MDC，优化器，UOW Waiting，UOW Exeucting等概念）
不多时，跑过来另外一个出纳MM。鉴于刚才1234号的悲惨遭遇，这位MM心虚地问：我是1235号，请问还能为您做点什么么？
大菠萝呢，推了推鼻梁上黑客帝国型的墨镜，咳嗽了一下，又从包包里面掏出一把花花绿绿的纸片。
什么咚咚？只听大菠萝说话了：这些呢是这几年来俺老板买的银行债卷，每年都买的哦~~~俺老板想要兑换出一部分不知道行不行啊
大菠萝的老板何许人？marcozeng是也，那可是金融界赫赫有名的大亨，MyBank银行最大的VIP客户之一哦。
说回那银行债券，自然是按照年份排好的。2001年的债券有自己的一套账本，2002年的也有自己的一套账本，2003年的自然也有自己单独的账本……也就是说，尽管这些信息都是有关债券的，但是物理上他们的信息是根据年份的不同分布在不同的账本上。这一套账本可以被看作债券的分区表，而作为区分不同账本的年份则是表分区键。
这样做有什么好处呢？比如你看现在，大菠萝说，我要把05年的债卷兑现五百万，都要100块一张的面额的；但是从06年的债卷里面要我兑换3000张50块面额的；07年的债券里面兑换5000张20块的现金（难道是要做什么不正当交易？要不拿那么多现金干啥）。这样把债券信息按照年份分类的好处就是可以不用在乎其他年份的，只需要关注05，06，07年三年的数据就可以拉~~~
不过marcozeng作为VIP，银行自然不能跑去问你提那么多现金干啥，只能老老实实照办。但是这么多钱，光装出来就要3大箱子，大菠萝一个人弄不走，怎么办？
大菠萝说了，这些钱先放到俺老板在银行里的保险柜好了，我们明天来取。
由于marcozeng是VIP，每一位VIP在银行里都有一个单独的保险柜。在每个保险柜里面呢，又有好几个小格子可以按照100/50/20/10块的面额把钞票码放整齐。在这里，如果把整个VIP保险库看作一个大的表，那么VIP账号则可以看作一个维度（每一个VIP都有属于自己的一个保险箱），然后这个箱子里面的不同面额类型的小格子可以被看作第二个维度，这样如果在提款的时候说：我要从marcozeng的保险箱里面提出100张50块面额的，银行的出纳小姐可以很快地找到钱在哪里。这个就是所谓MDC（多维群集）的概念，换句话说，就是把一种东西按照多种条件排列整齐（VIP姓名与钞票面额），使得查找数据变得更加方便。
不过这个1235出纳MM好像是新来得，不知道银行里那么多讲究，也不清楚该从何入手去查那些债券信息，于是跑去问主管。
主管一听就乐了，说你把那些账本拿出来，只用看2005，2006，2007年的就够了，然后把提出来得钱从上面划了，然后把现金弄出来，按照VIP名字找到他的保险箱，按照面额码放到小格子里面不就好啦。
这个主管就是优化器了，在代理进程不知道怎样访问数据的时候找到一个最有效的方法，告诉代理进程该怎么弄，然后代理进程就会根据指示去完成任务鸟。而这一长串只是就是所谓的访问计划。如果出于什么原因大菠萝同学过一会提出一个同样的要求，1235号出纳MM已经记住了怎么做这种业务了（SQL在package cache里面，不需要再次生成访问计划），就不用跑去问主管，自己按照指示在做一次就好了。
过了好一会，1235号出纳MM才跑出来，说：大哥，钱都给你整理好了，就等你明天来取了。还有啥要帮忙的不？
大菠萝坐在那说话了：你先忙你的去，我再想想还有啥要办的。
于是1235小姐可算脱身了，忙不迭地跑到另外一个窗口去服务下一个客户（stealing agent），大菠萝这个应用程序呢还占着窗口不走（应用程序UOW Waiting），也不办理业务（如果办理业务，在db2里面该应用程序就是UOW Exeucting状态拉），搞得后面好多客户都没有窗口只能排队 （窗口数量就是max connection的设置，出纳小姐的数量就是maxagent，如果窗口被占满了，后面的那些应用程序就连不上数据库咯）。
不知道这位大菠萝同学还需要办理什么业务呢？
===========================================
（这部分介绍事务，锁，死锁，锁等待超时，crash，crash recovery等概念）
不一会，只听大菠萝“哎呀”一声，惹得银行里的众人都转过头来看怎么回事。
旁边一位膀大腰圆的保安虎着脸，指了指墙上贴着的“安静”两个大字。
“差点忘了件重要的事……”大菠萝嘀咕道。
“小姐，俺还要给俺老板的员工发工资，他们的账号和要发的工资数额都在这里。钱从这个帐号扣除……”对着另一位刚刚跑来的1236号出纳MM，大菠萝说道。
说着，大菠萝递过去一个小本子，上面四五十页都密密麻麻地写满了员工的账号和工资……
出纳MM有一股想要吐血的冲动，不过还是忍住了，于是开始从小本子的第一个帐号开始，一点一点地从指定帐号扣钱，然后转入员工的账号。
为了加快速度，出纳MM没有转一笔帐就确认一次，而是转十笔帐才在电脑上点确认按钮一次（事务提交）。
不过就在操作过程中，出纳MM突然“咦”了一声：“好像这个员工帐号现在有人在查询，我需要等他查完了才能转帐，要不然他看到的结果可能就不正确拉。（锁等待，互斥锁等待共享锁）”MM指着小本子里面的一条记录说道。（因为数据修改后，在提交之前，我们并不能保证用户在未来是会真的提交还是会撤消交易--回滚--所以在修改时会请求一个互斥锁，也就是说当时不能有别的交易访问这条记录。而共享锁的意思就是说可以有很多人同时看这条记录，但是不能有别人修改）
大菠萝左右扭扭头，确实发现几个公司中熟悉的面孔出现在MyBank银行里。
就这样，大菠萝和出纳MM就在那里大眼瞪小眼地等着。不多时，柜台值班经理巡视的时候跑过来问：“哎，你们那几个出纳员，怎么闲着不干活啊？”
1236号出纳MM指着不远处的一个同样闲着等什么的出纳MM说：“我在等她确认查账完成阿（等待另一个应用的提交）”。
值班经理又问那个MM：“那你呢？”
另一个MM委屈地指着1236号出纳说：“我在等她确认修改记录的提交啊……”
“怎么回事？”值班经理纳闷了，怎么两个MM互相等啊？
原来另外这个出纳MM查账的时候不是查一个账户，而是夫妻两个人的账户，而恰好这对夫妻都在marcozeng手下的同一个公司上班，而更巧1236号出纳MM已经修改了老婆的数据，但是还没有修改老公的数据，而且也没有提交；但是另一个出纳MM是查完老公的账号后没有提交就跑去查老婆的账号……这样一来，察看老婆账号的请求首先要等1236号MM提交记录，因为1236号MM已经修改了数据了。但是1236号MM同时也在等这个出纳MM确认交易，因为查找老公的账号完成后还没有提交，这就出现了两边互相等待的情况，也就是出现死锁拉。
用时间图表示就是
出纳1236 -------修改老婆账号----------------------修改老公账号 （等待0000）
出纳0000 --------------察看老公账号------------------------------察看老婆账号（等待1236）
经理一看这样怎么办啊，于是就随便指了指两个出纳MM的其中一个，说你把你刚才的交易撤销，然后重新做一遍吧（值班经理就是死锁监测器db2dlock进程，而巡视一趟的时间就是DLCHKTIME参数定义）。
于是另外那个出纳MM一脸不高兴地回去撤销自己的交易了。
不过还没两秒钟，只听旁边一个座位上的大叔大喊起来：“你们有没有搞错，我都在这里等了20分钟了，你tmd一直在说别人的交易正在运行，不让我查账……”
话还没说完，左右两个穿着保安制服的彪形大汉就一左一右地把他架起来，拖到银行门口，一脚踹了出去（应用程序锁等待超时，连接中断了……），然后目无表情地指了指墙上“安静”两个大字……
全场的人那叫一个寒的说……
不过这不影响大局，银行依然是井然有序地帮助一个个客户处理业务，而大菠萝的那个小本子也已经翻到最后一页，马上就要完成了……
这个时候，忽然银行里所有的电脑和灯一下子都灭了。“哇，整个小区都停电了……”所有的业务都不转了，没有电脑怎么工作？ （实例崩溃，crash了，小区就是实例，如果小区里面有若干个银行，所有银行都不工作了就……）
半分钟不到，灯又亮了，不过很多人的交易只处理到一半，怎么办？现在暂时自然不能办理客户业务了，首先要把已经确认的交易真正落实下去（比如取款的，可能已经从账户上扣了钱，点了确认按钮，但是还没有把现金给客户（db2中的概念就是脏页还没有刷新到磁盘）），还有的则是要把没有确认的交易撤销掉。比如刚才大菠萝的这个交易，最后７，８个员工的转账还没有点“确认”按钮就停电了，所以银行必须把这个没有确认的交易撤销掉，已经划走的钱要重新弄回来，已经存进去的钱要取出来（回滚）。只有当这些操作都做完了以后（crash recovery完成）银行才能继续恢复对外业务。
折腾了好一会，终于弄得差不多了。于是银行重新开了所有的窗口，排队的人呢则需要重新领号（应用程序重新连接）。
这次还是挺幸运的，大菠萝又领到了一个靠前的号码，很快就排到了一个窗口。里面的出纳MM帮助大菠萝把剩下的几个员工的工资发了，然后大菠萝拍拍包包，说：今天的任务终于完成了，我走了哈，明天来提款……
就这样大菠萝施施然地走出了银行大门（应用程序断开连接），哼着１８摸得小调渐渐地消失在远方……
（鸣谢大菠萝友情客串演出，marcozeng补充内容，同时兼任VIP客户）
大家还有什么其他的概念可以放到这个场景里，欢迎补充哈:) 能弄成故事接龙最好^_^ [ 本帖最后由 wangzhonnew 于 2008-12-11 23:03 编辑 ]收起