如何设计基于Borland Midas的三层架构？

关于Borland的MIDAS各处介绍颇多，这里不作概念性的介绍。MIDAS 建立在TRemoteDataModule上，即建立在COM+上。在数据库应用中、数据库的并发操作是经常发生的，尤其是在关键任务（如银行、邮政、医院、电子商务等）应用中，所以要设计多层架构的中间层必须满足并发请求的需要。所以TRemoteDataModule的模式必须选用多线程的方案。但是，是不是每一个需要COM服务的客户都开一个线成为之服务是最好的呢？

在非冲突的数据访问的计算任务中是这样的，但在有冲突的数据库访问的时候就不是了。例如客户C1要想对表T1进行插入，客户C2要想对表T1进行查询，由于不知道港插入的数据是否在查询的范围，所以主流数据库系统（如Oracle，MS SQL等）都在客户C1对表T1进行插入的时候锁定了整个表或页，客户C2必须等待。这时候即使C1和C2用不同的线程执行也不会提高整体性能，相反还要付出数据库进行调度的代价。

由于Apartment线程模式只提供了4倍于CPU个数的线程创建能力，所以TRemoteDataModule所用的Apartment模式也只有4倍于CPU个数的线程。这样远远不能满足更多用户并发访问的请求。而采用Neutral模式了之后，并发访问的TProvider就不再是客户独享了，所以所对应的TDataSet的状态冲突管理成了令许多程序员头痛的突出问题。

一般地的说，客户数=COM实例数>线程数>数据库连接数。所以COM实例分配到线程需要适当的调节，不幸的是，现有的机制只提供了平均分配的算法，而我们更希望基于COM任务负担的分配算法。由于COM实例数>线程数，所以，在Borland的TRemoteDataModule上放置数据库连接和TDataSetProvider是不明智的，因为多出来的COM得不到线程服务（即处理机），所以闲置，给数据库造成多余的调度负担和保持网络连接的通讯负担。这样，合理的机制至少需要一个COM调节器，一个线程调节器，一个数据库连接调节器。

接下来，我们看看Borland的TDataSetProvider、TDataSet裔（如TTable、TQuery、TADOTable、TADOQuery等，下仅称TDataSet）和TDCOMConnection（或TSocketConnection，这还需要一个Socket中转的服务器）、TClientDataSet搭配的一种情况。当TDataSetProvider接上TDataSet后放在TRemoteDataModule，客户端用TClientDataSet连接TDCOMConnection（或TSocketConnection）访问时，TDataSetProvider从所连接的TDataSet得到数据，打包后通过COM机制发给TclientDataSet。

之后呢？当TClientDataSet由最终用户改动后执行ApplyUpdates，结果让我们大失所望，TDataSetProvider所连接的TDataSet的数据并不改动！

TClientDataSet通过CommandText执行的SQL更不用说了,不仅TClientDataSet自己的数据不改动（即使该SQL修改了本TClientDataSet所对应的表），TDataSetProvider所连接的TDataSet的数据一点都不改动。换而言之，TDataSetProvider所连接的TDataSet不能和后台的数据库系统数据同步，因而不能循环被多个TClientDataSet使用，即，没有缓存数据的作用，所有客户都分别通过中间层从数据库服务器上分别取得数据，而不因为有一个中间层而省了什么。

所以，我们不能指望不编写代码就能实现真正的多层架构来提高在不同的网络通讯能力的环境的应用的性能了，Borland没有提供便利的MIDAS，只是一个数据代理而已。

上述的三点讨论，我们希望的基于COM的真正的多层架构至少需要一下要素

1 用于管理配置的GUI用户接口，2 COM服务器和客户端，3 多线程，4 数据集，5 数据提供者，6 数据库连接，7 暂存数据的数据集，8 SQL执行器，9 COM调节器，10 线程调节器，11 数据集调节器，12 SQL执行器调节器，13 数据库连接调节器，14 数据压力指示器，15 商业业务监视处理外挂接口

下面对SQL执行器和其他6个调节器进行讨论。

如何设计基于Borland Midas的三层架构？: 一、 SQL执行器

这里的SQL执行器要求能分离两种SQL请求，一种是简单的对单一的不易改动的数据表的查询、增加、删除、更新，这一种SQL应该由有SQL执行器实现，但数据还是来源于数据库，并且和数据库同步更新。至于分布式中间层的同步通过刷新实现。为什么这一功能由SQL执行器实现而不是只由数据库实现呢？因为上面所讨论的，中间层应该具有暂存数据集的能力，暂存的数据由中间层加以维护会减少数据库和网络的压力，这才能体现中间层存在的必要性，更何况现在的网络情况大部分是:客户和中间层之间的链路带宽比较大（一般是局域网），而中间层和服务器的带宽相对比较窄（一般是距离远的局域网或广域网），所以中间层的暂存能力显得非常重要。

这种数据在本文简称为数据集。另一种SQL是操纵较容易改动的或极易改动的业务相关的表或复杂查询，这样的SQL由于涉及分布式修改，各个中间层之间的同步维护比较困难而且开销比较大，所以仍交给数据库服务器实现比较合理。

如何设计基于Borland Midas的三层架构？: 二、 COM调节器

调节COM分配给线程。一般来说，在多线程的COM中，一个客户连接一个COM实例，而多个COM实例分配给一个线程，开始时采用平均分配策略，当搜集的关于效率数据足够时，把任务轻重不一的客户的COM实例分配给一个线程，使得每一个线程的负担趋于平均化。调度的过程可能引起客户离线再重新连接。COM调节器单独调度，不受线程数目、SQL执行器数目、数据库连接数目的影响。

如何设计基于Borland Midas的三层架构？: 三、线程调节器

基于一段时间的运行后的经验，按照某数学模型创建线程个数。该数学模型应考虑数据集个数、SQL执行器个数、数据库连接个数对实际执行率的影响，考虑相对COM个数，以便减少轮候的时间。线程个数还受数据库连接个数的制约，因为多个线程共用一个数据库连接也会导致执行轮候现象。好的设计应该还有一个线程用于SQL后执行（back call）器，这个线程在没有任务时挂起。对于SQL后执行器的用途下面讨论。

如何设计基于Borland Midas的三层架构？: 四、 数据集调节器

正如上面的讨论，数据集是相对静态的表，例如较少改动的字典对照表（如:省市代码对照表等），一般用户以只读模式打开，应用程序管理员（下称管理员）以读写模式打开，并且不经常改变。数据集由设计人员设计时指定，少数可以由管理员指定。数据集调节器主要调节多个COM实例分时取用、必要时进行复制以便并发使用。

如何设计基于Borland Midas的三层架构？: 五、 SQL执行器调节器

调节SQL执行器的个数。调节SQL执行器的个数为:线程数+1个用于数据集+x个用于SQL后执行器。由于SQL执行器的创建和回收都比较容易和开销小，因而多产生几个并不会带来什么不良开销，所以SQL后执行器可以随用创建。后执行器是一种在独立线程执行的机制，用于中间层能独立维护错误而不是用户维护错误的情况（例如日志，可以在中间层恢复正常后补增执行）等。后执行器没有效率上的要求。

如何设计基于Borland Midas的三层架构？: 六、 数据库连接调节器

一般的安排是:视乎网络和数据库服务器的处理能力设定固定个数的据集连接。一般地说，流行的数据库服务器的多连接调度能力很强，所以尽可能的每一个活动的线程都创建连接。但是，基于网络的考虑，基于分布式应用中终端客户甚多的情况，设计者可能限制中间层连接的个数，于是连接数少于SQL执行器，调节器需要平衡SQL执行器的负担来分配连接。

在这种情况，由于SQL执行器的执行受到轮后的影响，从而影响了线程调度器的调度。另一种情况是，当用户对某个表的更新操作（INSERT、UPDATE、INSERT）的时候，数据库锁定了整个表，查询（SELECT）操作就在数据库处于等待了状态，直到上述更新操作完成，数据库连接的利用还要对所操作的表错开。

如何设计基于Borland Midas的三层架构？: 七、 数据压力指示器

向客户报告数据集的传送效率、SQL执行的耗时等信息。

综上所述，设计基于COM的Borland MIDAS的三层架构解决方案，需要解决COM实例、线程、数据集和所操纵的表的冲突、数据同步的问题。