进程间数据通讯要注意的问题

    由于在项目开发需要，我提供了一个dll给java调用，其中的java通过jni调用dll中的接口，然后把数据传输给我的一个读取数据，进行数据处理的进程。 这就需要在进程间进行数据共享。在进程间进行数据共享的方法很多，想必很多人都知道：
一、 Windows共享数据段内的全局变量
1)#pragma data_seg(".MYDATA")
//变量定义
int i = 0;
#pragma data_seg ()
#pragma comment(linker,"/SECTION:.MYDATA,RWS")

2)在DEF文件中加入下面:
SECTIONS
.MYDATA READ,WRITE,SHARED
在DEF文件中加入
SECTIONS
.MYDATA READ,WRITE,SHARED
的效果等同于#pragma comment(linker,"/SECTION:.MYDATA,RWS"). 
     没有多久，共享数据的dll就开发好了。然后我开始写了2个c++程式进行了测试，一切ok。然后我用Jbuilder写了一个java调用dll的jsp程式，在JBuilder里面也测试，通过。然后我把这个小的web项目打包成war，部署到我们的应用服务器上，它的环境也是tomcat5.0，和我本地测试环境一样。这时问题出现了，在我本地Jbuilder里面测试通过的程式，到了应用服务器怎么也不行，我的c++的读取程式，可以收到jni调用dll的接口发过来的准备读取数据的semaphone，但是当我的c++读进程读取里面的数据时，却根本收不到数据，好像设置的共享数据段根本没有起作用一样，开始我还以为他们调用的不是同一个dll，经过察看，发现不是这个原因引起的。
    然后我又用我的写一个c++模拟那个写进程，发现又可以。用我本地的JBuilder调试也可以。就是到tomcat里面就不行了。想。。。。。。
    然后我看到Jbuilder启动tomcat的方式是 C:\Borland\JBuilder2005\jdk1.5\bin\javaw -classpath "C:\Borland\JBuilder2005\thirdparty\jakarta-tomcat-5.0.27\bin\bootstrap.jar;C:\Borland\JBuilder2005\jdk1.5\lib\tools.jar"  "-Dcatalina.home=C:/Borland/JBuilder2005/thirdparty/jakarta-tomcat-5.0.27"  -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=PCHENJUN:32169,suspend=y org.apache.catalina.startup.Bootstrap -config D:\testCallDll\Tomcat\conf\server8083.xml start 这样的，也就是用java调用tomcat的一个主类启动的，而我的应用服务器启动tomcat的方式是通过服务器的方式。然后我把启动tomcat的帐号换成了系统帐号，换成administrator的帐号，还是数据不能共享。
   而我把应用服务器上的tomcat的启动方式换成和我本地一样的方式，即用java启动tomcat又可以了，再测试，数据交换成功。
   现在问题定位就是启动方式有问题，也就是只要这2个读写进程，已2个用户登录分别运行，就不能共享数据。然后我再次用2个远程连接到我的服务器上，2个远程连接的用户名一样，在1个远程连接上运行写进程，无论是c++写的那个模拟写进程，还是那个java进程，在另外一个远程连接上运行读进程。这个时候为问题就和一个在服务里面运行，一个在正常的shell里面运行一样，数据不会交换。
         结论： 也就是我最后找到的
    “Memory in Shared Code Sections Is Not Shared Across Terminal Server Sessions”（共享代码节中的内存不在终端服务器会话间共享）(Q251045)

Memory in Shared Code Sections Is Not Shared Across Terminal Server Sessions

View products that this article applies to.

Article ID	:	251045
Last Review	:	November 1, 2006
Revision	:	3.2

This article was previously published under Q251045

SYMPTOMS

On Microsoft Windows NT 4.0, Terminal Server Edition, memory in shared code sections of system global DLLs is shared across terminal server sessions.

On Windows 2000, however, memory in shared code sections of system global DLLs cannot be shared across terminal server sessions. Instead, each session receives its own instance of the variables that are declared within a shared code section. That memory is shared among processes that are running within the same session, but is not accessible to processes in other sessions.

Back to the top

CAUSE

New architecture of Windows 2000 memory manager prevents shared code sections from being shared across terminal server sessions.

Back to the top

RESOLUTION

To resolve this problem, obtain the latest service pack for Windows 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

260910 (http://support.microsoft.com/kb/260910/EN-US/) How to Obtain the Latest Windows 2000 Service Pack

Back to the top

WORKAROUND

If an application needs to share memory across terminal server sessions on Windows 2000, it should do so through a global file mapping object.

Back to the top

STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Windows 2000 Service Pack 1.

Back to the top

MORE INFORMATION

On computers that are running terminal server, you can register a DLL as a system global resource. For additional information on how to perform this registration, click the article number below to view the article in the Microsoft Knowledge Base:

186625 (http://support.microsoft.com/kb/186625/EN-US/) Terminal Server Commands: REGISTER

Back to the top

---

APPLIES TO

•	Microsoft Windows 2000 Server
•	Microsoft Windows 2000 Advanced Server
•	Microsoft Windows 2000 Professional Edition

Back to the top

Keywords:

kbhotfixserver kbqfe kbbug kbfix kbkernbase kbqfe kbtermserv kbwin2000sp1fix KB251045

Back to the top

 

转载于:https://www.cnblogs.com/Frodo/archive/2008/03/20/1114894.html