在客户端/服务器的工作模式下，客户机处于主动状态，发送请求给监听状态的服务器，后者处理后再将结果返回给客户机。 在这种工作模式下，客户端只与服务端联系，因为它不处于监听状态，所以无法收到服务端或其他客户端“不请自来”的信息。这导致一个现象发生：当某个客户端修改了服务端的数据后，其他客户端不能实时获知，以至这些客户端所获取的数据过时。目前解决的主要方法是客户端周期性向服务器端获取数据，即使这些数据并没有变动。这导致两端都浪费了资源。 POSTGRESQL能较好地解决这个问题。POSTGRESQL是个开源数据库，功能齐全，性能优异，其好处这里不多描述，大家可以去（)了解. POSTGRESQL有两个SQL语句 LISTEN和NOTIFY。 LISTEN NAME 让当前连接处于监听状态，监听名为NAME的NOTIFY的到来。 NOTIFY NAME 发送名为NAME的NOTIFY事件给之前已经LISTEN NAME的所有客户端， NOTIFY事件格式含有NAME和PID两项，LISTEN方可以根据PID项获知是哪个进程发送。举个例子：所有客户端想及时了解表AAA更改事件，于是它们就发送LISTEN AAA命令监听该事件的发生（取AAA名，只是直观点，主要看大家的约定）。当某一个客户端修改了表AAA，就发送NOTIFY AAA命令，于是所有客户端就收到了这个通知，知道表AAA已经被别人修改。 LISTEN/NOTIFY具体应用请看POSTGRESQL文档。 俗话，好马还要好鞍。既然数据库有如此好的功能，若接口不支持，也是白搭。POSTGRESQL的各种接口目前只有C接口libpq.dll和JAVA接口JDBC有封装这功能，其余接口如ODBC，OLEDB等都没封装，原因是，不当当是接口要封装了此功能，同时客户应用程序要有监听机制，才可以收到这些“不请自来的”的通知。C和JAVA可以设计成多线程，让某个线程阻塞IO进行监听，另一线程可以正常工作，是不会影响应用的运行的。而其他用ODBC接口C的应有程序如PB、VFP等，很难设计成多线程，所以这些接口封装LISTEN/NOTIFY也没有多大意义。 既然应有程序不是多线程，但WINDOWS操作系统是多线程，是否可将这些“不请自来的”的通知转化为WINDOWS的消息流呢？而大部分应用程序是可以处理自定义消息的。答案是可以的，这是我在ODBC封装NOTIFY/LISTEN的思路。在ODBC中非调用时间执行WSAAsyncSelect，当一个“不请自来的”通知（其实网络包）到达时，会将网络事件转化为消息，应用程序可以设计MESSAGE_HANDLE来处理这些消息。 我把PSQLODBC8.01.02版本的源程序稍微修改后，重新编译，使ODBC封装了此功能。经测试，在各种开发语言是可以成功运行的。具体的使用方法请参照压缩包里的“说明”文挡和例子。 |