关于同步更新控制的方案比较

应partech的要求，就避免两人非事务同步更新控制的一些方案做一些讨论和比较。有兴趣的朋友，可以先看看http://forum.iteye.com/viewtopic.php?t=12849&postdays=0&postorder=asc&start=0这个帖子。
    我想请partech就我的这些疑问给出一些答复，
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

partech 写道:
赫赫，除非你不用ORMapper,而是程序中直接写SQL。否则你需要在领域对象中跟踪属性的变化。

按照我说的方式的测试结果接近半秒，你们这个8CPU，14G内存的服务器也够可以的了，这么垃圾还不扔掉。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
凤舞凰扬 写道：
呵呵，恕我无知，我倒是要你告诉大家，有哪些个ORM工具采用了你所说的方式？也就是说哪个ORM工具生成的SQL是你说的这种？
再者，你不是强调你做了测试么？简单，把你的测试类贴上来，大家就按照你的测试类来测试，比较比较就是，不要老是自己空谈。
第三，我从来都不否定你的做法是种解决方案，但是在大量字段及可能存在批量更新却又受某些约束的情况下，你的做法并不可取。采取你这样的方式，就必须在整个操作流程中（从数据库查询－页面处理－页面提交－数据库存储）都必须保留old record,如果是批量的更新（想想吧，你更新或者试图删除100个对象，那么你在提交的时候也要提交100个old object），可不可取，楼上把你所谓的测试代码拿来，我给你应用个场景，让你好好看看就是。
第四，关于楼上并发的（在后面的帖子）的论断，有些文不对题，这根本不是什么并发问题（并发的问题完全可以由事务来处理），这种问题属于一种更新约束的问题。简单地讲，如果约束的条件一定，那么这种问题也不存在，为什么？其实就是可以在一个事务中在更新前对约束条件进行查询判断。但是如果约束条件并不一定（也就是说无法或者成本太高地去穷举可能出现的约束条件时），戳是一个非常理想的解决方法，也是绝对被广泛应用的解决方法。
第五，关于楼上（后面的帖子）的“从聚合的主/从领域对象来看，
是不允许外部对象直接引用从对象的。”又是一个错误的表述，我想楼上对UML似乎不太清楚，什么是聚合（aggregation）？聚合是指有两种对象A和B，B相对独立，但是B又是A的构成部分，这称为聚合。如果B不是独立的，B必须依赖于A而存在，那么A和B的关系是复合（Composition）。只有复合关系，是不赞成外部对象直接单独引用，同时也请注意一点，也只是不能直接单独引用，并不是说不能引用。也就是说如果要引用一个复合对象中的子对象时，必须同时引用其所对应的主对象，这样才能保证所引用的子对象依旧从属于主对象。
第六，关于用delete/insert代替update的方法，这是一个解决方案，也是大多数应用的解决方案，但并不能说这是一个非常好的方案，它只是在某些条件下（比如很难做到脏数据的判断，尤其在基于web的操作方式时）的一种替代而已。楼上前面不是大谈所谓的ORM么？倒是顺便问问，哪些ORM采用的是楼上这种操作方式？
第七，关于所谓的采用全字段匹配更新还是戳，性能问题只是一个方面而已（其实在某些情况下，也是重要的方面），楼上先回答完第一个问题和第七个问题，后面的答案就自然出来了。
第八，楼上始终回避一个问题，如果表中含有blob,clob(text,image,binary）这样的字段时候怎么办？甚至简单一点，如果表中含有大量的大型字符描述字段（比如varchar 1000以上）的时候又怎么办？呵呵，这个时候性能的关注点就不仅仅是速度了吧！
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
    再就partech在上个帖子所做的测试进行简单地说明一下，我希望partech在两个不同的进程进行两个不同的更新（而不是在每个进程中进行两次更新），并且保证第一个进程在执行完关闭连接。在这样的情况下，再请发表你的测试结果。
    楼上想主要和我探讨两者在性能上的差别，好，我就请楼上把你所谓无太大差异的实际应用拿来（主要是以示公平），我来给你做个应用场景（其实这个应用场景非常简单，就5个用户并发更新50个对象，而每个对象具有30个字段，并包含10个具有100个字符的字符串），给你做一个在对象数量，以及速度上的比较出来。也好供大家参考。

考虑到交互的友好性，建议你把问题整理一下，好吗？不觉得很乱？
再有你的问题大多都可以单独成帖，一次只解决一个问题，我不习惯这种把所有问题都混在一起的思维方式，别人看起来也费劲。
并且你最好给出你的思考和解答，而不是节外生枝，抓不住重点。

在这个贴里，我只就测试作些答复。

不知道为什么你不明白？我做的两次测试你对比两次的第一个Update语句就是了。两次测试是在不同的进程不同的连接里进行的。最好不要指挥我做什么，给出你的疑问就好了。

具体的应用不可能拿出来，不过可以告诉你是证券交易系统。

那就麻烦解答下面几个问题吧！
1. 如果在表中字段含有blob, clob字段的时候，怎么实现更新控制？
   我的答案是通过所谓全字段匹配根本就无法做到。
2. 如果表中字段含有大量的描述性字符字段（比如有上5个甚至更多的超过varchar500的字段）的时候进行批量更新，采用全字段匹配的控制，性能又会如何？
   会非常容易地发现性能的相当大的差异，我要拿出例子非常容易，只是怕楼上又不承认，最好你自己好好尝试先
3. 我想请问楼上的更新SQL语句中的where条件怎么构造，楼上在前篇帖子说我不会用ORM,我假设楼上使用的是ORM工具来做，那么我请楼上告诉我，你用的是什么ORM工具？如果是自己写的，为此产生的性能损耗会比不采取这种方法大多少？据我所了解的，在最流行的几个ORM工具中，还没有看到采用楼上所谓的方式来构造SQL的。假设就是楼上自己写的组件，我倒是很想看看楼上的实现，我来帮你做做单元测试就是
4. 我想请问在评估性能的时候包括些什么？
  性能主要指运行的速度以及对内存的要求，对于程序而言，简单地说就是程序执行的速度与程序所产生的对象数量，在楼上的解决方案中，每次提交更新都需要将所持有的原对象从web提交回（当然也可以采用所谓的缓存保存，但是始终避免不了要保存该对象），对于批量更新，以及多用户操作，始终都回避不了数据对象的double，楼上又是否做过评估呢？
5. 网友Lee给了一个简单的场景应用，但是楼上却给了一个犯了基本错误的解答 ，如果可以，请楼上再试图解答解答这个问题吧。
  楼上在对UML的聚合、复合理解上就出现了偏差，得出了一个所谓不允许外部对象直接引用从对象的的结论，如果这个直接引用的意思是“单独地直接引用”那也还是正确。对于楼上的解决方案，再看看使用戳的控制方式吧，当第一个更新成功，不管它修改了什么，它都更新了戳，而戳只对主对象有效，第二个更新过来时，它不拥有最新的戳，那么它就无法更新。好好比较这两个解决方法吧，100个子对象（做过订单系统的人都知道，很正常），就必须保持100个DELETE语句，如果并发用户比较多的时候，楼上，这样的性能比较还要怎么说明么？
6. 关于使用DELETE/INSERT代替UPDATE，这是一个有效的解决方案，但是它是最佳的么，我想问问，有多少ORM采用的是如此方法？
  好像我还是没有看到
    恕我如此之烦琐，而且有这么多所谓的“偏题”，原因是楼上许多言论中的问题实在是太多，而且很多都是没有办法再自圆其说，去解释的。
   楼上如果不愿意回答（如果烦，可以按点一个个回答就是），也无所谓，不过我相信，这样的帖子，完全可以让很多朋友去比较去了解。

回答完这些问题你可要请客，要不我就亏大了，浪费了我好多宝贵时间。
问题1.你是指Blob不能使用在Where子句中使用"="？那就试下like，Oracle没试过，DB2可以。
问题2.用这个问题来谈性能？OLTP的系统，你要求使用ORM的方式进行批量更新？外加
大量字符串？并且要求要快？最后要求能防止并发冲突？有意义吗？能给我一个实际的应用场景吗？
你已经作过测试了吗？怎么证明就发现性能有相当大的差异了？
问题3.JJYAO已经回答你这个问题了.
问题4.不知道你想知道什么.
问题5.建议你仔细阅读DDD中的第六章Aggregates节。
问题6.你没看到的东西多了。是不是最佳别来问我。

第一个问题，哈哈，BLOB可以用like???是Clob吧，Blob是二进制的存储，你怎么个like?再说了，呵呵，亏你居然还要强撑用全字段匹配，真是“佩服”极了你。BT一点，BLOB字段中保存了一个doc文档，呵呵，楼上比较比较试试看。
第二个问题，哈哈，连OLTP都用上了，拜托搞清什么是联机事务先。批量更新一些数据，怎么就不能用ORM了？难道用ORM，表中的字段就不能含有一些长的描述性字符串字段？（5个不算多吧）这种用戳来实现控制完全没有性能问题的怎么就不能谈性能问题了？性能问题从来不是所谓场景和要求，根本就是采取策略的错误与失败。
第三个问题，
控制并发更新，本身就不是任何一个ORM工具的要求，而是一个业务上的要求（任何的在事务环境中的先后更新操作完全不违反数据库的事务要求，而只是在一定需求下违反了业务需求，比如讲一个订单在confirm后就不能修改）。再说了，YYJAO的回答并不准确，因为订单项属于订单的一部分，订单项的改动，本身就应该视为订单的改动（客户修改了订单项，对于客户服务人员来说就是修改了订单。）。
第四个问题，楼上前面在和我讨论的时候，总只是评估执行的速度，但是否想过采取你的方法所带来的对象产生数据量的剧增，光不说别的，就是构造这样的SQL的代销都要大蛮多的。
问题五，楼上这么明显的错误还要争，真是服了你了，贴些连接，你好好看看，学习学习UML先。http://ootips.org/uml-hasa.html http://forum.java.sun.com/thread.jspa?threadID=581239&tstart=210
问题六，回答不出，居然用 的回答，实在太经典了，我的确视眼有限，很多没有看到过，既然楼上使用了，说出来啊？至于Insert/Update是不是最佳，我前面的帖子已经完全说明了，才不会问你，而且也问不出什么。
    不是我不想请楼上吃饭，但是楼上的这种看待问题的态度实在让我没有兴致了。我更不想故意找楼上的茬（各位看官看看争辩的来源就会知道），本来我只是“诲人不倦”地讲讲道理，解释之间的差别，结果楼上变成了死撑着，一副即使错得有些离谱的时候仍然一副我行我素的样子，结果越说越错，越错越说。
    我自然不能通过几许文字就能让你怎么样，或者我的话语也有些让你难堪。但是技术是实在的，经验也是需要总结和累积的。光靠撑是撑不住的。

看到你的答复确实让我感到难堪。
第一个问题：
------------------------------------------ 脚本 ---------------------------------------------------
无标题1
-----------------------------------------------------------------------------
CREATE TABLE DBO.FORBLOB ( B BLOB  (1000   )  NOT  LOGGED  NOT  COMPACT   )

DB20000I  SQL 命令成功完成。



INSERT INTO FORBLOB (b) VALUES (blob('dd'))

DB20000I  SQL 命令成功完成。



SELECT b FROM FORBLOB WHERE b LIKE blob('dd')



B                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 

-----------------------------------------------------------------------------

x'6464'                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           



  1 条记录已选择。





drop table dbo.forblob

DB20000I  SQL 命令成功完成。

第二个问题：
没有应用场景，也就是说没有需求，你说的这种测试意义何在？

第四个问题：
评估速度是有前提的，看看需求是否需要；

第五个问题：
你关于“组合”同“聚合”的概念在UML无疑是正确的。
但是我感打赌，你没有很好的实践过。
既然你不喜欢去查书，我就贴上书中
的一小部分论述好了。
Say you were deleting a Person object from a database. Along with the person go a name, birth date, and job description. But what about the address? There could be other people at the same address. If you delete the address, those Person objects will have references to a deleted object. If you leave it, you accumulate junk addresses in the database. Automatic garbage collection could eliminate the junk addresses, but that technical fix, even if available in your database system, ignores a basic modeling issue.

Even when considering an isolated transaction, the web of relationships in a typical object model gives no clear limit to the potential effect of a change. It is not practical to refresh every object in the system, just in case there is some dependency.

The problem is acute in a system with concurrent access to the same objects by multiple clients. With many users consulting and updating different objects in the system, we have to prevent simultaneous changes to interdependent objects. Getting the scope wrong has serious consequences.

哈哈，继续..........
第一个问题，楼上解决了BLOB中是二进制的问题么？我想问，如果BLOB字段中存储的是DOC文档，怎么办？你怎么like?
第二个问题，楼上置疑应用场景，好，我就描述一个场景“在一个客户定义生产订单处理中（如汽车、电子产品，包括各种备注、设计准则及条款以及用户描述），订单处理管理者（可以是系统，但一般角度都是人）需要每隔一段时间对处于非正常状态（比如延期，暂时失效等）进行状态的批量处理和标识。订单对象一般由数十个字段以上组成（同时构成复合对象），其中有相当的长字符串描述字段。在批量更新中，如果此时有某些订单得到更新，则应被忽略。”这样的场景在任何一个Booking Handling以及Supply Chain Management系统中都是非常的常见。
第四个问题，比较空，再怎么讨论也得不到什么结果。留待网友们参考。
第五个问题，哈哈，我不清楚楼主怎么得出个没有好好实践过的观点（我可不是专业的UML研究者），我们就你贴的东东来讨论讨论先。我们先讨论文章的第一个段吧。文中第一段举了人员与地址的例子，这里面有两个问题，第一，address是否考虑作为基础数据，第二，在人员信息表与address信息表中是否需要考虑外键。（这两个问题可以看看我曾经也发过帖子的，数据库外键的使用），如果按照文中的说法（似乎是想形成一个悖论），如果单独删除就会存在空的引用，如果选择了一种级联删除的方式来表达它违反了对象建模的基本准则（其实这是很明显地不恰当地比较，将一个关系物理模型的技术处理与对象模型的准则去比较）。其实按照文中的理解，基于OO的角度来看，address是不能被删除的，因为它已经被其他对象如Person所引用。不清楚文中为何偏偏没有概述这一种选择（只能说这是为它后续内容作铺垫罢了）。文中第二段，即使在一个事务中也不能采用级联的处理方式，这个很对。文中第三段，倒是有些和我们现在讨论的问题相关，不过它只是表明不得不去处理相关对象的同步（注意啊，是 interdependent objects,不是current object），如果按照文中的意思，对象间的相互同步不是采用事务（文中第二段描述了），那么就会存在并发问题（这个问题还不是我们讨论的解决方法的问题，下次另开贴讨论）。简单描述一个这样的场景，根据楼上的UML图来说吧，假如A将汽车轮子改为50cm直径，B将轮子改为80CM直径，那么汽车的轮子直径是多少（当然前提要假设汽车copy了轮子的值）？我们先来解释一下什么是并发问题，并发是因为同步访问的原因从而导致结果的不确定。也就是说，因为更新轮子和更新汽车不在一个事务环境下（按照文中第二段的意思），那么在A和B同时更新轮子的时候，就无法确定汽车的轮子直径（因为无法确定A和B在后续处理中更新汽车的顺序），也就造成了更新不同步的问题。再回头看看我们所讨论的问题吧，我们是讨论，如果A更新轮子，B也更新轮子，那么轮子的结果是多少？如果单纯从结构和设计上来说，只需要考虑最新的更新，它不存在任何不同步的问题。我再简单举例说明在业务需要上需要考虑单个对象处理的同步问题。简单说，汽车现在生产好了，A操作让它出厂送交客户（会产生送货单发给客户），B操作进厂修理（也许外漆没有喷好），A操作先进行。但是需要要求所有的汽车出厂后都必须经过某些流程才能改变其状态（比如客户退货，客户送修等），这个时候，如果简单地使用B是最新更新，就更新数据的话，那么就会导致业务处理的不同步或者说异常。有人此时会说，那我更新的时候判断状态就是啊，首先很多数据并不是用单个状态来标识业务状况的，其次单纯的一个状态就会导致必须针对每一个业务处理使用一次条件或者判断，对于维护以及实现都是相当烦琐，并且非常容易出现遗漏。
    看来，楼上对于问题的理解就存在了偏差，我倒是很乐意了解楼上所贴的引用文章（以免断章取义招来口舌），希望能贴个下载的连接。
最后，让我们来看看楼上所贴的图吧。我不清楚图是从哪里截取来的，但是里面有两个问题，第一，如果图中确切的使用的是aggregation，那么tire就是有自己的生命周期，customer怎么就不能引用轮胎了？呵呵，汽车的customer自然不能直接引用tire，因为它关心的是car而已，但是如果customer是其他汽车制造商或者轮胎销售代理商呢？也不行么？这里面涉及到一个custmoer对象的细分与业务要求的问题而已。第二，如果customer只能是购买汽车的customer，而所有的外部引用只是以car的形式表现（比如做的是汽车销售系统的订单处理），那么只用aggregation来描述car与所属对象的关系并不够充分（只是不充分，因为UML允许以association来代替aggregation,composition,也运行以aggregation代替composition，在很多书中，建议UML的实践人员在划分不清关联的三种类型的时候使用引用关系较弱的类型代替），正是因为这种不充分，反而让楼上理解错误了aggregation和composition的区别。在第二种情况，如果要强调描述car所属对象不能被外部引用时应该使用composition。好，我们再看看就是对于composition，外部对象是否又可以引用的情况。我先说个场景"如果汽车某个部件出了问题，比如wheel，它属于保修期，汽车送往销售商修理，销售商更换了车轮，那么车轮的保修期会是哪个保修期呢？"任何一个修个产品的都知道，如果产品还剩一个月保修期，更换了零件，那么该零件的保险期将按照它独自的保修期来计算。我想问问楼上（顺便也问问大家），在这个时候，在客户的保修单中是不是需要额外引用该轮子的数据？（我假设新轮子和旧的坏轮子不是一个品牌，那么也就不是一个数据，同时原始的信息是需要保存的，这样可以避免有些朋友提出直接更新原轮子保修期的想法）同样，在汽车的维修记录对象中，又是否要引用轮子的信息呢？

第一个问题：
结果都作到这样了，你还说不行？然后转移问题变成如果是DOC怎么办...
DOC就是大一点还有什么本质的区别吗？
第二个问题：
能否再具体点，给出Order的表结构，“在批量更新中，如果此时有某些订单得到更新，则应被忽略”这是什么意思？
第五个问题：
真是的佩服你，就这点断章取义的片断，你就能发表如此的大段的论述。
图和片断都是DDD里的
Domain-Driven Design: Tackling Complexity in the Heart of Software
自己找找吧。

     最近很忙，很久没有上来，呵呵，看来我不说服你我还真是不罢休了，哈哈。
第一个问题，doc文档和字符串没有区别嘛？在你的例子中你所用的只是普通的字符，也就是ascii的字符，所以这样的比较还可以，如果不是ascii字符，或者说根本就不能用任何字符串所描述，也就是二进制的数据（doc就是这样），你怎么个比较法？居然说没有区别？
第二个问题，我说得如此详细了，还没有看懂，好吧，我再给你详细些，管理员（或者系统本身）对一批订单进行封藏处理（比如将单的状态改为延迟生产或者挂起等）的时候，已经有其他的操作员对该单进行了处理（比如核价，订原料，或者其他等等），那么针对这个单的封藏处理将要被忽略。
第五个问题，我从来不想去断章取义，所以在我的回复里从来没有你所引用的文字有错误什么，但是我非常坚信，它只是为了证明某个观点而假设了某些约束而已。我用那么长的文字描述和解释了区别，楼上看也不看，闻也不闻，实在让我无法可说，到这个时候，我相信其他看客们觉得有自己的想法和意见了。
    说到这里，这个帖子也该封了，倒是有时间看看楼上提供的这本书，好好看看它到底是怎么说的。

去看看jDBC的实现吧。是可以直接使用BLOB类型作为参数的。
给出的示例是表示可以用通过like比较BLOB，字符串是先转化为BLOB后才LIKE。
真糊涂假糊涂？
第二个问题你不给出表结构，就没法评价。
最后的问题你还是看了书再说吧。关于“组合”同“聚合”的概念，前面已经说过
你的概念是正确的。我只是希望知道你是如何实现的，它们在实现时是否有差异？
又及，你的论述我是认真看过的。