3,245
社区成员
发帖
与我相关
我的任务
分享ATL问题，高分
如果我做网站使用的COM是不是应该选择Dynamic DLL,而不是 EXE 和SERVICE
ATL COM中 什么时候使用support MTS选项？这样做有什么好处和弊端
当我新建一个ATL COM项目，并仅仅选择Dynamic DLL 和 SUPPORT MFC的时候
INSERT ATL OBJECT的时候 ：选择Category中的Objects的时候，右边的Simple Object,
Add-in Object ,Internet Explorer Object,ActiveX Server Component, MMC Snapln,
MS Transation Server,Component Registrar Object应该选择哪个呢？这些接口在编程的时候有什么不同？我实验了一下，选择
Simple Object和ActiveX Server Component的时候我向其中添加完全相同的接口，从asp页面中调用的时候效果完全相同，如果我只是想用其写一个组件供asp页面调用， 在这个组件中实现
对数据库的操作，那么我应该选择哪个选项才能保证功能实现并且效率和稳定性相对高一些？
当insert ATL Object的时候在选项页中的Attributes页中的三个选项Threading Model,Interface,
Aggregation都是什么意思啊，我应该选择哪个呢？
ATL COM中 什么时候使用support MTS选项？这样做有什么好处和弊端
当我新建一个ATL COM项目，并仅仅选择Dynamic DLL 和 SUPPORT MFC的时候
INSERT ATL OBJECT的时候 ：选择Category中的Objects的时候，右边的Simple Object,
Add-in Object ,Internet Explorer Object,ActiveX Server Component, MMC Snapln,
MS Transation Server,Component Registrar Object应该选择哪个呢？这些接口在编程的时候有什么不同？我实验了一下，选择
Simple Object和ActiveX Server Component的时候我向其中添加完全相同的接口，从asp页面中调用的时候效果完全相同，如果我只是想用其写一个组件供asp页面调用， 在这个组件中实现
对数据库的操作，那么我应该选择哪个选项才能保证功能实现并且效率和稳定性相对高一些？
当insert ATL Object的时候在选项页中的Attributes页中的三个选项Threading Model,Interface,
Aggregation都是什么意思啊，我应该选择哪个呢？
...全文
请发表友善的回复…
发表回复
librastar2001 2003-09-30
- 打赏
- 举报
选择SUPPORT MTS 然后注册成COM+组件服务器，就可以满足你的并发要求了。
在COM+的安全设置当中设置各种使用权限就可以达到你的要求。
不需要加代码。
在COM+的安全设置当中设置各种使用权限就可以达到你的要求。
不需要加代码。
sunht 2003-09-30
- 打赏
- 举报
如果一切按照VC的默认模式，那么还需要在编程过程中考虑线程安全吗？
比如，并发访问这个组件的时候，这个页面调用，那个也调用，需要怎么在代码中处理？
比如，并发访问这个组件的时候，这个页面调用，那个也调用，需要怎么在代码中处理？
qwedcxza 2003-09-30
- 打赏
- 举报
support MTS 使得你的 DLL 支持微软事务服务器
你的应用应当选择 simple object, 因为你只是从页面调用这个组件，而无需组件关联到页面
线程模式决定了对象引用和释放时的线程安全性
接口类型一般使用 dual, 这个你应该参考关于 IDispatch 的内容
Aggregation 指定对象能否被聚合
你的应用应当选择 simple object, 因为你只是从页面调用这个组件，而无需组件关联到页面
线程模式决定了对象引用和释放时的线程安全性
接口类型一般使用 dual, 这个你应该参考关于 IDispatch 的内容
Aggregation 指定对象能否被聚合
wuxfBrave 2003-09-30
- 打赏
- 举报
the class allows its interfaces to be exposed by a container class as if these interfaces were the container's own interfaces
no 表示不能
yes The COM object can be created directly or it can be aggregated. This is the default
only The COM object cannot be created directly and can only be aggregated. When you call CoCreateInstance for this object, you must specify the aggregating object's IUnknown interface (the controlling IUnknown).
no 表示不能
yes The COM object can be created directly or it can be aggregated. This is the default
only The COM object cannot be created directly and can only be aggregated. When you call CoCreateInstance for this object, you must specify the aggregating object's IUnknown interface (the controlling IUnknown).
wuxfBrave 2003-09-30
- 打赏
- 举报
Interface 选择接口类型，建议选择Custom，从IUnknown接口派生COM接口
dual 从IDispatch接口派生服务器内部的接口
dual 从IDispatch接口派生服务器内部的接口
LeeZi 2003-09-30
- 打赏
- 举报
Dynamic DLL 不要SUPPORT MFC
Simple Object就可以了。
其它默认就可以了。
Simple Object就可以了。
其它默认就可以了。
wuxfBrave 2003-09-30
- 打赏
- 举报
ThreadModle表示选择线程模型
Objects created in a single-threaded apartment (STA) receive method calls only from their apartment's thread, so calls are serialized and arrive only at message-queue boundaries (when the Win32 function PeekMessage or SendMessage is called).
Objects created on a COM thread in a multithread apartment (MTA) must be able to receive method calls from other threads at any time. You would typically implement some form of concurrency control in a multithreaded object's code using Win32 synchronization primitives such as critical sections, semaphores, or mutexes to help protect the object's data.
When an object that is configured to run in the neutral threaded apartment (NTA) is called by a thread that is in either an STA or the MTA, that thread transfers to the NTA. If this thread subsequently calls CoInitializeEx, the call fails and returns RPC_E_CHANGED_MODE.
When a thread is initialized through a call to CoInitializeEx, you choose whether to initialize it as apartment-threaded or multi-threaded by designating one of the members of COINIT as its second parameter. This designates how incoming calls to any object created by that thread are handled, that is, the object's concurrency.
Apartment-threading, while allowing for multiple threads of execution, serializes all incoming calls by requiring that calls to methods of objects created by this thread always run on the same thread – the apartment/thread that created them. In addition, calls can arrive only at message-queue boundaries (i.e., only during a PeekMessage, SendMessage, DispatchMessage, etc.). Because of this serialization, it is not typically necessary to write concurrency control into the code for the object, other than to avoid calls to PeekMessage and SendMessage during processing that must not be interrupted by other method invocations or calls to other objects in the same apartment/thread.
Multi-threading (also called free-threading) allows calls to methods of objects created by this thread to be run on any thread. There is no serialization of calls – many calls may occur to the same method or to the same object or simultaneously. Multi-threaded object concurrency offers the highest performance and takes the best advantage of multi-processor hardware for cross-thread, cross-process, and cross-machine calling, since calls to objects are not serialized in any way. This means, however, that the code for objects must enforce its own concurrency model, typically through the use of Win32 synchronization primitives, such as critical sections, semaphores, or mutexes. In addition, because the object doesn't control the lifetime of the threads that are accessing it, no thread-specific state may be stored in the object (in Thread-Local-Storage).
Objects created in a single-threaded apartment (STA) receive method calls only from their apartment's thread, so calls are serialized and arrive only at message-queue boundaries (when the Win32 function PeekMessage or SendMessage is called).
Objects created on a COM thread in a multithread apartment (MTA) must be able to receive method calls from other threads at any time. You would typically implement some form of concurrency control in a multithreaded object's code using Win32 synchronization primitives such as critical sections, semaphores, or mutexes to help protect the object's data.
When an object that is configured to run in the neutral threaded apartment (NTA) is called by a thread that is in either an STA or the MTA, that thread transfers to the NTA. If this thread subsequently calls CoInitializeEx, the call fails and returns RPC_E_CHANGED_MODE.
When a thread is initialized through a call to CoInitializeEx, you choose whether to initialize it as apartment-threaded or multi-threaded by designating one of the members of COINIT as its second parameter. This designates how incoming calls to any object created by that thread are handled, that is, the object's concurrency.
Apartment-threading, while allowing for multiple threads of execution, serializes all incoming calls by requiring that calls to methods of objects created by this thread always run on the same thread – the apartment/thread that created them. In addition, calls can arrive only at message-queue boundaries (i.e., only during a PeekMessage, SendMessage, DispatchMessage, etc.). Because of this serialization, it is not typically necessary to write concurrency control into the code for the object, other than to avoid calls to PeekMessage and SendMessage during processing that must not be interrupted by other method invocations or calls to other objects in the same apartment/thread.
Multi-threading (also called free-threading) allows calls to methods of objects created by this thread to be run on any thread. There is no serialization of calls – many calls may occur to the same method or to the same object or simultaneously. Multi-threaded object concurrency offers the highest performance and takes the best advantage of multi-processor hardware for cross-thread, cross-process, and cross-machine calling, since calls to objects are not serialized in any way. This means, however, that the code for objects must enforce its own concurrency model, typically through the use of Win32 synchronization primitives, such as critical sections, semaphores, or mutexes. In addition, because the object doesn't control the lifetime of the threads that are accessing it, no thread-specific state may be stored in the object (in Thread-Local-Storage).
wuxfBrave 2003-09-30
- 打赏
- 举报
3.Threading Model 表示选择线程模型
Objects created in a single-threaded apartment (STA) receive method calls only from their apartment's thread, so calls are serialized and arrive only at message-queue boundaries (when the Win32 function PeekMessage or SendMessage is called).
Objects created on a COM thread in a multithread apartment (MTA) must be able to receive method calls from other threads at any time. You would typically implement some form of concurrency control in a multithreaded object's code using Win32 synchronization primitives such as critical sections, semaphores, or mutexes to help protect the object's data.
When an object that is configured to run in the neutral threaded apartment (NTA) is called by a thread that is in either an STA or the MTA, that thread transfers to the NTA. If this thread subsequently calls CoInitializeEx, the call fails and returns RPC_E_CHANGED_MODE.
When a thread is initialized through a call to CoInitializeEx, you choose whether to initialize it as apartment-threaded or multi-threaded by designating one of the members of COINIT as its second parameter. This designates how incoming calls to any object created by that thread are handled, that is, the object's concurrency.
Apartment-threading, while allowing for multiple threads of execution, serializes all incoming calls by requiring that calls to methods of objects created by this thread always run on the same thread – the apartment/thread that created them. In addition, calls can arrive only at message-queue boundaries (i.e., only during a PeekMessage, SendMessage, DispatchMessage, etc.). Because of this serialization, it is not typically necessary to write concurrency control into the code for the object, other than to avoid calls to PeekMessage and SendMessage during processing that must not be interrupted by other method invocations or calls to other objects in the same apartment/thread.
Multi-threading (also called free-threading) allows calls to methods of objects created by this thread to be run on any thread. There is no serialization of calls – many calls may occur to the same method or to the same object or simultaneously. Multi-threaded object concurrency offers the highest performance and takes the best advantage of multi-processor hardware for cross-thread, cross-process, and cross-machine calling, since calls to objects are not serialized in any way. This means, however, that the code for objects must enforce its own concurrency model, typically through the use of Win32 synchronization primitives, such as critical sections, semaphores, or mutexes. In addition, because the object doesn't control the lifetime of the threads that are accessing it, no thread-specific state may be stored in the object (in Thread-Local-Storage).
Objects created in a single-threaded apartment (STA) receive method calls only from their apartment's thread, so calls are serialized and arrive only at message-queue boundaries (when the Win32 function PeekMessage or SendMessage is called).
Objects created on a COM thread in a multithread apartment (MTA) must be able to receive method calls from other threads at any time. You would typically implement some form of concurrency control in a multithreaded object's code using Win32 synchronization primitives such as critical sections, semaphores, or mutexes to help protect the object's data.
When an object that is configured to run in the neutral threaded apartment (NTA) is called by a thread that is in either an STA or the MTA, that thread transfers to the NTA. If this thread subsequently calls CoInitializeEx, the call fails and returns RPC_E_CHANGED_MODE.
When a thread is initialized through a call to CoInitializeEx, you choose whether to initialize it as apartment-threaded or multi-threaded by designating one of the members of COINIT as its second parameter. This designates how incoming calls to any object created by that thread are handled, that is, the object's concurrency.
Apartment-threading, while allowing for multiple threads of execution, serializes all incoming calls by requiring that calls to methods of objects created by this thread always run on the same thread – the apartment/thread that created them. In addition, calls can arrive only at message-queue boundaries (i.e., only during a PeekMessage, SendMessage, DispatchMessage, etc.). Because of this serialization, it is not typically necessary to write concurrency control into the code for the object, other than to avoid calls to PeekMessage and SendMessage during processing that must not be interrupted by other method invocations or calls to other objects in the same apartment/thread.
Multi-threading (also called free-threading) allows calls to methods of objects created by this thread to be run on any thread. There is no serialization of calls – many calls may occur to the same method or to the same object or simultaneously. Multi-threaded object concurrency offers the highest performance and takes the best advantage of multi-processor hardware for cross-thread, cross-process, and cross-machine calling, since calls to objects are not serialized in any way. This means, however, that the code for objects must enforce its own concurrency model, typically through the use of Win32 synchronization primitives, such as critical sections, semaphores, or mutexes. In addition, because the object doesn't control the lifetime of the threads that are accessing it, no thread-specific state may be stored in the object (in Thread-Local-Storage).
天限天空 2003-09-30
- 打赏
- 举报
如果我做网站使用的COM应该选择Dynamic DLL support MTS
ActiveX Server Component
ActiveX Server Component
