WCF程序 多个客户端使用同一数据库连接产生的问题

既然你用WCF，为什么还让客户端连接数据库呢？

重新设计一下！

客户端只知道服务器的存在，数据库对客户端应该是透明的；

客户端只是想服务器发出请求，至于该请求的处理是对于数据库还是内存或者其他，客户端不需要知道，只要得到服务器的处理结果就可以。

另外，无论客户端还是服务器，用一个数据库连接是不应该的，遇上多线程就麻烦了：不做同步处理会产生错误，做同步处理效率又不行……

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

你数据库连接使用不对，如果只用一个连接，别说事务，就是并发的普通处理都可能异常；应该每个请求都创建连接、打开、关闭、释放。

自己写了个事务处理类，提供一个静态的启动事务方法，然后就是Commit,Rollback方法，再利用GUID作为事务ID。有事务处理类管理本地数据库链接和远程跨域服务信息，利用这些信息在Commit或者rollback时进行提交或者回滚，在数据库级上并行执行命令，需要对远程跨域提交或者回滚的，结合一个远程事务池、远程事务服务类和远程事务服务调用代理类(就提交和回滚两个方法)进行处理，其中用事务ID贯穿始终。当然，所有的数据访问层，数据库访问层都来由一个事务类参数，没有事务的话就为空。由逻辑处理层决定是否采用事务处理。做的就这么简单，结果感觉还可以；当然这个模式有个致命的弱点，就是无法解决Commit一致性问题，就是如果涉及到多个数据库时，如果前N-1个数据库服务都提交成功，第N个数据库提交失败就没办法了。在跨区域事务方面问题比较大，但如果是局域网还是可以的。这种方式比较适合数据分布存储（非镜像）的情况，当然，数据分割的时候需要将大部分的 *** 作都集中在一个中心，毕竟跨区域访问还是有些慢得。

这次整得这个架构，可以分布式查询，同时更新多个数据库（可以控制到表级），并对业务逻辑层透明，速度和易用性感觉都还不错，而且业务层处理事务的时候可以支持搭积木方式进行。

这个架构带有云应用架构的味道，可以分业务，分用户存放数据，应用部分也可以支持多中心，多负载方式，理论上来讲扩展性无限。当然，因为主要的目的不是做镜像同步支持，所以我没有加入数据库命令队列处理方式来保证可靠性，在数据库节点方面只是简单的采用了同时更新3份，查询则随机选其中一份的方式。对于企业级业务，特别是高实时性和一致性的应用，如果跨数据库，事务处理和可靠性保证要一起做，真的很难。所以后来放弃了自己做可靠性那部分（就是同时写3份，随机读一份那部分功能），让数据库自己去做，毕竟他们更专业。

这个架构主要技术点：多线程（实现不同目标数据库查询异步进行），ODPNet,WCF(跨域访问),事务，同步（简单的采用Lock），反射机制，泛型等.

WCF数据库开发一般分下面几步：

1. 接口定义， 即常说的contract接口

2.接口实现，即实现contract的接口

3. 接口托管，将写好的接口部署到wcf托管程序里，譬如IIS,console，windows service，WinForm

4. 在接口实现里完善数据库访问的代码。此段代码与传统的C/S两层 *** 纵DB无差异。

---