| xiong's profile共享空间标题PhotosBlogLists |  Tools  Help |
|
September 28 DCOM/COM+ "Logic thread" "causality" "reentry" “Concurrency" NTADCOM/COM+ "Logic thread" "causality" "reentry" “Concurrency" NTA
Guidelines to help understand it:
STA thread needs to pump message. It is important, but there is no need for you to over consider it. You just need to ensure your function does not block the message loop. When you make an outbound COM call, COM runtime helps maintain the loop, not your job.
COM runtime keeps message loop for outbound call in STA thread. COM runtime does NOT keep message loop for outbound call in MTA thread.
In regular STA COM component, message loop decides everything. If message loop runs, any call is able to come in if the COM STA component lives in this thread. Reentry is NOT a special case.
Causality is not designed for COM or COM+. It exists in RPC layer.
In regular COM, causality exists, but it does not affect COM behavior. Causality only affects in COM+ when COM+ Concurrency is considered.
When COM+ requires Concurrency, we have a process wide lock in client. When you tried to enter an activity while the causality is different, the call will be rejected with error.
The host may use any kind of to support STA thread pool. For example, COM+ uses STA thread pool by default. For singleton STA component, you will find multiple STA threads are executing with the same this pointer. For ATL DCOM, you can use CAtlAutoThreadModuleT to support thread pool.
Thread pool model affects behavior. If single STA thread is used to host STA COM objects, when reentry occurs, the calls are placed in the single thread with FILO way. If host supports STA thread pool, the reentry may be dispatched to separate thread, and executes simultaneously.
COM+ design goal is different from regular COM. Regular STA COM is designed to kill DLL hell as function call, status maintained, and thread safe. COM+ is designed as enterprise service supported with large scalability. You can play with COM, but COM+. One client, one NTA object, one job, one Causality, status less, never callback, never pass object pointer, are the best practice for COM+
最近这几个名词快把我给弄死了。一个挖石油的，你管这么多干啥。特别是那个causality，整个互联网上只有Don Box的一片文章说到了这个东西，写作时间还是99年5月。现在都06年了，也没人弄清楚到底是个啥 整个业界里面介绍COM+的书不少，但是烂书更多。大致把"causality", “Concurrency"说清楚估计就两本:
O'Reilly - COM and .NET Component Services
Transactional COM+ : Building Scalable Applications 但是我保证这些资料也就能让您弄明白这玩艺是什么意思，怎么用，我至今也没看到资料。
有一个客户端CLR WinForm程序，一个DCOM。DCOM暴露了一个event, WinForm用connection point的方法来订阅(subscribe)这个event。另外还有一个单独的程序(叫做程序A好了)，负责让DCOM触发(fire)这个event。这个架构很标准对吧。
当event fire的时候，客户端WinForm程序的某个方法就会执行。这个执行链接就是:
程序A -----> DCOM ------>客户端WinForm
现在客户端WinForm的响应方法里面，弹了一个MessageBox，现在我一直都不去点这个MessageBox
接下来说一下问题:
1. 程序A有没有hang在那里
2. 如果再启动一个程序A的进程，那个进程能再发一个event到那个DCOM里面吗？ 3. DCOM会收到这个event的触发调用吗？还是会通过返回错误的方法立刻拒绝？还是先block在那里 4. 如果DCOM会受到这个触发调用，DCOM通过connection point去调用客户端WinForm的响应方法吗？ 5. 如果DCOM决定调用，客户端会看到两个MessageBox吗？ 事实是，程序A hang了。如果再启动一个程序A的进程,这一串调用会成功，而且会看到两个MessageBox。
如果你还不觉得很神奇，那我继续问:
1. 实现event source的DCOM object要是singleton对吧。这个STA object怎么可以同时执行两个调用呢？
2. 客户段的第二个MessageBox怎么出来的？在新的线程里面执行的？ 3. 出现两个MessageBox的时候，如果点掉第一个MessageBox，保留第二个MessageBox，程序A的hang会解除吗？ 还不够神奇的话，请把这个DCOM的代码编译成DLL，放到COM+里面去看看，结论一样吗？
我本来想解释一下的。不过我现在终于明白为什么没有资料把这个东西解释清楚了。因为只有两种情况:
1) 当你需要思考这个东西的时候，你肯定会自己去测试，因为不看到callstack,一切都是白说
2) 如果你根本就没有思考过这个东西，我说了你也不懂 所以，你才看到了文章前面那一大段我的洋文总结，而不是细致的带callstack的分析
Comments (8)
TrackbacksThe trackback URL for this entry is: http://eparg.spaces.live.com/blog/cns!59BFC22C0E7E1A76!1634.trak Weblogs that reference this entry
|
|
|
