做一计费系统,程序是永久运行,而计费规则是一次性读入,缓存在内存中,于是出现一个问题:当在数据库中修改计费规则的时候必须重新启动程序。重启当然不太好,于是考虑了一种方案:在每天凌晨3:00重新载入一次计费规则。
基本上来讲,这样也就行了。不过如果能实时反映数据库中的数据,似乎这缓存机制就更好了。主动向应用程序发消息的办法倒是没找着,不过想到了xp_cmdshell存储过程。
于是得一方案:
1.单独写一个程序暂且命名为“触发程序”,一运行即根据main(string[] args)参数args通过win API:PostMessage发自定义消息给计费程序。(计费程序的句柄可以运行时便写入文件中,触发程序从文件中读取)
2.建一个针对计费规则表的insert,update,delete触发器。
3.触发器调用xp_cmdshell,参数是触发程序的路径,并可以通过args传递参数。
4.计费程序重载DefWndProc函数来处理这个自定义消息,在这儿重新载入计费规则。整个方案就是这样,关键在于触发器、xp_cmdshell、进程间通信。不知道这样实现是否会存在安全问题或其它问题?

解决方案 »

  1.   

    如果触发程序仅仅是为这一个目的而做,没有其它的表需要监听的话,用信号量来作为进程同步也不错,只是Visual Studio.NET 2003没有信号量,2005已经有了。
      

  2.   

    这样做,好象数据库服务器和应用服务器一定要在同一台机器上。
    在触发器里执行xp_cmdshell没什么问题,关键在于xp_cmdshell到你的进程间通信这一块,不知道如何实现。
      

  3.   

    刚才的只是想法,我现在一试,似乎不能发消息!xp_cmdshell有限制?担心安全隐患?不允许程序向外部发消息?
      

  4.   

    我是用PostMessage,直接运行没任何问题,计费程序总是可以收到消息。
    可通过xp_cmdshell运行就不行,计费程序收不到消息。(我是用文件存放计费程序的handle,通过Console.Write发现触发程序取handle是没问题的,并且PostMessage也正常执行了,但似乎事实上消息并没有真正发出)
    (Console.Write的内容会作为xp_cmdshell的返回值出现)                                  ----楼主
      

  5.   

    我再试试xp_cmdshell里可不可以用UDP。
                                            ----楼主
      

  6.   

    UDP还是可以,测试通过。
                                                ----楼主
      

  7.   

    可以使用 SQL2005 中的 Notification Services 来实现
      

  8.   

    用UDP通信就可解决数据库服务器和程序服务器不在同一台机器上的问题。用这种方案,我们甚至可以通过TCP连接相互通信,然后可以把应用程序执行的有用结果保存到数据库中。                                                 ----楼主