RT。我现在知道有两种方式,一是在数据库里使用存储过程,二是使用WCF。还有没有其它的方法?

解决方案 »

  1.   

    这是个很有意思的议题,实际上,如果从业务角度考虑,不光C/S, B/S也面临同样问题,我看过几款软件根本就没有考虑并发处理的问题,对于一个特定业务记录,两个不同的操作人员竟然都可以操作,这实际上是架构设计的问题,如对于一个入库单的操作,如果设计时允许多人处理,就必须对入库单记录用专有的字段标记,使某个人处理时其他人无法操作才行。
      

  2.   

    并发只是针对EDIT同一条数据而言的,创建和删除基本没有这可能吧.
      

  3.   

    另外,使用事务并不能解决竞争冲突问题,假设两个用户都对入库单验证,事务都可以打开,也都可以完成写入,如果没有查询工作,都会在commit后完成修改操作,这样就只能听天由命,看谁先操作谁倒霉了。
      

  4.   

    数据库本身带有排它锁,除非出现需要客户端确认,才需要做相应处理,[align=center]**********************************************
    欢迎使用 CSDN 小秘书
    http://blog.csdn.net/whowhen21
    **********************************************[/align]
      

  5.   


    感谢你深入地探讨此问题!在多客户端的系统里,系统是不应该把特定的业务单据作排它锁定的,就比如说入库单,A客户端添加一张E1的入库单,保存在数据库后停留在单据界面。此时B客户端通过查找E1入库单,也进入到E1入库单界面。这个时候系统里的E1就有3个版本,1)数据库版本,2)A客户端版本,3)B客户端版本。如果A客户端修改了E1的数据并保存,这时数据库与A客户端的E1数据是同步的,但B客户端的E1数据就是过时的数据了。若B客户端想修改E1的数据,B客户端就必须保证自己的数据与数据库数据是一致的,否则就会污染E1的数据。要解决多客户端的业务并发,我觉得还是要在客户端与数据库间增加一层逻辑,客户端不是直接连接到数据库,或者把增加的这一层逻辑放到存储过程里去,所以说使用数据库锁和事务我感觉并不能解决问题。我没有研究过其它一些占有率比较高的多客户端软件是如何解决这个问题的,基本上也看不到网上有讨论这个问题的话题,所以特地提出来,请大家畅所欲言。
      

  6.   

    不懂?!存储过程,跟WCF怎么对比起来了。既然使用存储过程,那么难道直接动态产生sql指令(哪怕是一参数形式)就不行了吗?而且这也不是性能的主要考虑啊。谁听说过移动公司说“我们的系统支持3亿手机,因为我们的手机都是调用SQL Server存储过程的”?C/S结构要解决任何灵活多变的业务问题,并且要达到专业的水平,经验上都是采取业务服务器与前端客户分离的思路,也就是说开发前端程序的人根本不要想当然地去假设后台使用什么数据库、使用几个数据库、有没有调用其它SOA服务等等。这样就能在系统重构的漫长过程中发挥出那些看懂了整个系统源代码的开发人员的积极性去改进架构。软件并不是在编码之前就设计出来了的。
      

  7.   


    谢谢您参与此话题!存储过程能解决我在9楼所说到的问题,因为它可以在内部添加逻辑判断。而WCF就专门是为解决分布式系统而开发的框架,并且从结构上来说,WCF(客户端除外)就是客户端与数据库中间的那层逻辑层,所以在1楼我提到了它们。是不是可以这么来说,多客户端的业务并发,只能是通过中间的逻辑层来解决?
      

  8.   

     如何控制并发,这个没有绝对吧,不然你就自己写个Gata专门访问数据库的,然后别的程序都通过访问这个Gata操作数据,这样不管多少客户端理论上的绝对相等时间,也不存在并发问题.
      

  9.   

    看到一个只言片语只有一两个需求功能名词的描述,它立刻就陷入“数据库和WCF”里边去了,这也“太快了”。你应该费时间研究一下业务描述,力求它是按照迭代规律来思考出来的设计,它只需要为一个月内的测试服务就够了。而不是想一次性搞定一个空洞的题目,然后发布一个学术论文。
      

  10.   


    使用“客户端<->数据库”模型的软件,要在每个操作前判断当前数据是否与数据库同步是很麻烦的,而WCF里有一个通知机制,让数据发生变化时自动推送到各客户端,这就解决了数据一致的问题。使用“客户端”<->“中间层”<->“数据库”模型的软件,所有客户端应该能够读取到最新版本的数据。至于中间层正在操作数据时,如何处理客户端的查询数据操作,我也没有想明白要如何处理。若做排它处理,则有可能引起长时间的锁定而浪费时间。不做排它处理也会发生数据不一致的问题。
      

  11.   


        我没有使过WCF, 但我和朋友交流时得知WCF真的很慢。使其实施了近两年的项目不得不完全推倒重来,从你提到的这一点,我感觉会不是这正可能: 
        我使用过REMOTING,知道REMOTING是建立在远程对象映射基础上的,数据是在客户端和服务器都存在一份拷贝,如果是某个具体数据变化倒好办,如金额变化,只会改变某个字段,而如果是对象变化就可能扔掉旧的,加入新的。而WCF只管理数据层面,很有可能是不管什么情况,只要变化就全部数据重新同步(我的猜测而已)。如果是这样的话就要命了。
      

  12.   

     如果抛开WCF,想象自己实施会有什么同步手段,那么不可绕过的就是数据变更的判断问题,可以采用的机制自然是timestamp了,
      

  13.   

    另外Remoting还有通信不稳定的问题,但好歹后台可以使用序列化的二进制数,而WCF使用XML,那么通信效率就太差了。
      

  14.   

    这个例子,主要是针对数据上来讲,难点是客户端显示的数据一致,否则会容易造成脏数据的更新。可以考虑socket 来刷新页面
      

  15.   


    请问慢到什么程度?
    我是最近两天才开始看WCF的教程的。客户端显示的数据是否要一致,我觉得要看应该场景。我更倾向于不同步显示,实现同步显示的话可能会消耗大量资源,只要保证某客户端处理的数据不是过时数据就可以了。