Compared with the traditional COM server, the asynchronous mode of COM can change the synchronous server to a two-phase Asynchronous Server. The word "Asynchronous" seems to be applicable to the aforementioned transaction Asynchronization, but it is slow. Let's talk about it carefully.
COM is indeed asynchronous. It provides polling and event methods. VS provides a powerful wizard, naturally, it can span process boundaries and machine boundaries (solving network transmission problems ).
However, the COM Asynchronous Server has the following problems:
1. The COM Asynchronous Server must be in the EXE format, which means that the call must span the process boundary, resulting in performance loss.
2. The call object must process only one call at a time. When the called object is processing another method call, the Begin method rejects the second call by returning RPC_S_CALLENDING. Well, this will have an impact on concurrency.
According to my test results on VMware running under P4 2.0 GB 2 GB memory, the approximate performance of cross-process is 20 thousand calls per second. Considering that most of the asynchronous operations may be slow database or file operations, the COM Asynchronous Server can be sufficient. However, if the machine boundary is crossed, I did not test it. It is estimated that it may be 1/10 of the Cross-process boundary.
If you do not have special performance requirements, the Asynchronous Server of COM is also quite usable, but it is used in scenarios where packaging is slower.
However, there is also a benefit to using COM. You can use ole db directly, and you can also use ADO if you are in trouble. In C ++, you can use ole db or ADO directly, performance should be the best.