DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
Generally speaking, programmers building distributed applications without using middleware have to handle the memory allocation and deallocation themselves.
For novice or inexperienced programmers, this can often cause problems as they are often not sure when to deallocate the temporary memory needed to handle a call, when the call has finished, and whether it is their responsibility to free memory or not.
The result is what is called memory leak where memory is continually allocated by the program, but not deallocated. In other words, programs allocate more memory than they subsequently free. Distributed applications are particularly prone to memory leakage on both the client and server side.
Some middleware products provide functions which handle memory allocation and deallocation automatically for the programmer and thus avoid memory leak. One particular products memory management functions are controlled by knowing the state of the RPC call. The memory management functions are thus triggered by the state of the RPC.
Where Microsofts tools are used, memory management can in some cases be handled by them. Where tools are not used, although the management of the Vtables is handled by DCOM, all other memory management has to be handled by the programmer using commands provided with DCOM.
The DCOM library provides a number of APIs which are used to get and free memory, as well as an interface through which methods can be called. The IMAlloc Interface has methods to allocate, reallocate, free, get the size of, and minimize the heap. The shortcut API commands also provided are CoTaskMemAlloc and CoTaskMemFree.
The way parameters are handled is dependent on whether they are in parameters, out parameters, or in/out parameters (used for both input and output). The rules are shown below:
In error returns, out parameters have to be set to a value which can be cleaned up without any action on the callers part, and all in/out parameters must either be left by the caller or be explicitly set as in the out parameter error return case. Thus, although memory management is supported by Windows NT with commands (interfaces really) to help the programmer manage his own memory, no automated services are provided. (It would be nice to see more help here. Memory management is such a pain in the neck it could use more support.)
One of the useful services which a middleware product can support is distributed shared memory. Distributed shared memory is the ability to access an area of shared memory on one machine from processes on other machines where these other machines may be running the same or different operating systems.
Distributed shared memory acts like a bulletin board with processes able to share memory across the network, posting data into memory, and accessing or retrieving data from it. Read and write operations should be serialized automatically and should be guaranteed to act atomically.
Generally speaking, the shared memory services provided by middleware products are better than those provided by operating systems. Where Unix is used, for example, the programmer has to program his application to serialize data access when using native operating system shared memory services.
By using the distributed shared memory services in middleware products, programmers should also be able to apply access controls to the data and lock the data. Byte level read or write access limits should be able to be imposed on all or parts of memory segments. Particular areas of segments should be able to be made read only or inaccessible for given time periods.
All or parts of memory segments may also be locked at byte level so that updates can be performed on the area. Read or write operations attempted against a locked area of memory are then prevented until the memory is subsequently unlocked. This feature has particular use on high performance applications to replace a DBMS.
Distributed shared memory services are not provided with DCOM, nor are they provided with Windows NT, and as such they are not likely to be provided with DCOM on other platforms. Windows NT does have support for shared memory on a single host. This provides a virtual memory system which enables up to 32 processes to read shared memory on the host (as long as the manufacturers HAL drives are installed).
The memory looks as though it is a file and supports paging, caching, buffering, and locking. Where SMP is supported, applications can share between processors. But this is not the same as distributed shared memory.
Previous | Table of Contents | Next |