|
|
马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有帐号？立即注册
x
ActiveServerPage技术为应用开发商提供了基于脚本的直观、快速、高效的应用开发手段，极大地提高了开发的效果。在讨论ASP的安全性问题之前，让我们来看看ASP是怎么工作的。程序
在前几章我们已看到COM+供应的几种运转期特征，它们使得散布式组件的开辟复杂化，这些组件可用于创立可扩大、可保护的ASP使用程序。MTS开始引进了事件模子，它的计划简化了基于组件的散布式事件处置体系的开辟。作为MTS的承继者，COM+加强并扩大了MTS的壮大的事件模子，给体系供应更多天真性和复杂化。
COM+事件模子往失落了庞大的事件处置代码，这些代码是经由过程MSDTC和谐散布式事件所必须的。可是更主要的是，COM+事件模子通明地交融了散布式事件与COM+组件。
经由过程利用声明(declarative)属性完成的COM+事件，偶然也称为声明事件或主动事件。声明属功能从内部指定到组件的完成。为此，必需：
?设置组件的TransactionSupport属性，利用ComponentServicesExplorer大概在组件范例库中利用一个常数值。
?可选修正组件来表决事件的了局。
经由过程代表组件与MSDTC交互，COM+主动地处置其他的庞大且冗杂的事件细节。
由于COM+依附于MSDTC和谐事件，单个组件可以在单个COM+事件中对分歧范例的数据源实行操纵。当与组件一同利用COM+声明事件时，能影响ADO或OLEDB数据会见。在单个事件中可以操纵的数据源的大概组合是无尽头的。比方，COM+工具可以在SQLServer数据库中修正数据、发送MSMQ动静，和操纵来自信型机体系的数据，一切这统统都在不异的COM+事件中。
如今我们分明了COM+事件的好处，上面持续进修怎样无效地利用声明事件模子并懂得COM+在“幕后”所做的事。
19.3.1TransactionSupport属性
正如下面提到的，每一个COM+组件的TransactionSupport属性决意了组件将怎样介入COM+事件。激活COM+工具时，COM+决意了工具的事件撑持和制造者是不是已供应了一个存在的事件。基于这两方面的信息，COM+运转期将在一个存在的事件或一个新的事件中供应工具，大概基本不存在事件。不论有无事件，都能激活每个COM+工具。因为这个缘故原由，使用事件的组件经常被称为事件性组件，没有益用事件的组件则称为非事件性组件。
利用COM+时有五种大概的TransactionSupport属性选项：
?克制(Disabled)当组件的TransactionSupport属性设置为Disabled时，COM+将完整地疏忽组件的事件请求。COM+起首试图在创立者的情况内激活工具。假如创立者的情况是有效的或不兼容的，COM+在一个新的情况中激活工具。因为工具大概承继或不承继创立者的情况，则工具也便可能共享或不共享创立者的事件。
?不撑持(NotSupported)当组件的TransactionSupport属性设置为NotSupported时，组件的实例决不介入事件。这类设置是为不会见数据源的COM+组件计划的，其了局是组件没有事件开支。但是，TransactionSupport属性为NotSupported的工具老是在一个新的情况中被激活。这与Disabled相冲突，Disabled的工具能够共享创立者的情况。NotSupported是缺省的TransactionSupport属性值。
?撑持(Supported)当组件的TransactionSupport属性设置为Supported时，组件的实例介入存在的事件。可是组件对事件并没有请求，组件在事件不存在的情形下仍能很好地实行。Supported属性只是暗示撑持事件，而不是必需请求事件存在。
?必要(Required)当组件的TransactionSupport属性设置为Required时，组件的实例老是在事件内实行。在激活COM+工具前，COM+将利用创立者的事件(假如存在)，大概新的事件供应工具。不论哪一种情形，组件实例老是在事件内实行。
?必要新建(RequiresNew)当组件的TransactionSupport属性设置为RequiresNew时，老是在一个新的事件中激活组件的实例，即专为这个工具创立一个事件，而不论是否存在可用的事件。这个设置为必需在事件中完成事情，但又必需把它的事情与一切其他的事件分隔的组件而计划的。利用这个设置时，COM+工具永久不会运转在创立者的事件中。新的事件完整自力于创立者的事件。
1.设置TransactionSupport
组件的TransactionSupport属性可使用组件服务扫瞄器(ComponentServicesExplorer，CSE)设置，大概在组件的范例库中指定一个缺省的TransactionSupport设置。在组件的范例库中指定一个组件的TransactionSupport属性是无益的，由于当利用CSE从实行这项义务中排除一个办理者时，能够削减不准确地设置组件的伤害。但是，记着在组件的范例库中指定的TransactionSupport属性是一个缺省值，可使用组件服务扫瞄器掩盖该值，这一点是很主要的。
在利用组件服务扫瞄器对一个组件的TransactionSupport属性举行设置时，复杂地翻开一个COM+使用程序的ComponentProperties对话框，从Transactions选项卡当选择五种大概的TransactionSupport属性设置中的一个，如9-5所示。
假如利用的是VC++，能够在组件范例库中为一个组件的TransactionSupport属性设置一个缺省值，可复杂地经由过程在组件的接口界说言语(IDL)的界说中增添响应的一行来完成。当该组件被加到一个COM+的使用程序时，COM+读取范例库而且主动地利用存储于该范例库中的TransactionSupport属性设置作为缺省值。
VisualBasic6.0也同意开辟者经由过程改动类模块的MTSTransactionMode属性，为组件的TransactionSupport属性设置指定一个缺省值。不要让这个属性的称号棍骗了你，MTSTransactionMode属性不仅与MTS一同事情，也和COM+一同事情。当编译一个项目时，VisualBasic将在组件的范例库中为TransactionSupport属性的设置安排一个等价的常量值，如9-6所示。
注重在VisualBasic中MTSTransactionMode值的手艺术语和组件服务扫瞄器中的术语是不完整不异的。但是，不用忧虑，除Disabled(对COM+是新的)外，每个TransactionSupport属性级别都有一个对应的MTSTransactionMode设置。表19-1中列了一切大概的MTSTransactionMode属性和他们的等价的COM+TransactionSupport属性。
当组件从RegisteredComponents列表中到场时，由于组件服务扫瞄器不读取范例库，因而只需组件用AddFile对话框加到COM+使用程序中，就使用贮存在组件的范例库中的TransactionSupport属性设置。相反地，从RegisteredComponents到场的COM+组件，假如不必组件服务扫瞄器修正它们的设置，则组件利用缺省的TransactionSupport属性设置，即NotSupported。
19.3.2举动与同步
当事件处置体系为很多用户供应服务时，能从客户中吸收同时产生的挪用。因而，事件处置体系必需思索像多用户并发、同步和线程办理等成绩。COM+可以处置这些成绩，并且同意创立在多用户散布式情况中实行的组件，其创立历程同创立为单个用户服务的组件一样。
COM+经由过程利用举动(activity)来完成这个惊人的义务。在MTS中，举动是一个工具组，这些工具都在代表单个客户运转。在COM+中，举动是一个情况组，这些情况在代表单个客户运转，情况大概含有一个或多个工具。但是，这仅是一个巨大的不同，而且能够以为情况是最外部的工具容器。
举动确保服务于统一用户的两个工具不会同时实行。在一个举动中的工具被同步以制止在这个举动中并行地实行。举动能够由几个情况(包括着工具)构成，能够运转在分别的历程中，大概运转在分别的呆板上(略微有一点限定)。因为这些缘故原由，举动偶然指的是运转的单个逻辑线程。
为何工具的同步云云主要？思索一个最糟的情形，在完整不异的时候，代表统一用户服务的两个工具试图会见不异资本。每个工具要完成本人的操纵，就要堵塞其他工具的运转。这类情形称为逝世锁。举动能避免产生逝世锁，这是经由过程每次只同意一个工具代表一个用
户运转来完成的。别的，举动在匡助COM+办理线程缓冲方面起侧重要感化。
在MTS中，举动内工具的同步是经由过程将举动毗连到单个物理线程，或是一个STA实行的。在一个举动中的工具不克不及并发实行，由于每一个举动唯一一个物理线程。别的，COM+利用庞大的锁定机制来确保举动中的同步。
每一个举动坚持着单一的独有锁。当在工具中挪用一个办法而且工具的情况存在于一个举动中时，在同意处置办法挪用前，COM+起首要试图取得举动锁。假如取得锁，就由工具处置挪用，直到办法挪用完成，才排除锁。假如不克不及取得锁，就堵塞办法挪用，直到取得锁才挪用办法。固然锁定历程加倍庞大，但从高条理概念看，COM+利用逻辑的举动使很多个情况和多个工具同步，基础上就是每举动用一个独自的锁。利用锁的历程如9-7所示。
情况能存在于创立者的举动或一个新的举动中大概基本没有举动。但是，单个情况不克不及超过多个举动。为了创建和坚持这些干系，COM+为每一个举动创立共同的用户标识符，称为ActivityID，存储于每一个情况中。
1.创立举动和Synchronization属性
跟着COM和MTS编程模子的集成，创立举动的办法也产生了改动。利用MTS，每一个工具属于一个举动。当VB客户利用CreateObject函数或New关头字(及某些表达式)，大概VisualC++客户利用CoCreateInstanceEX函数创立MTS工具时，主动地创立了举动。为了在已存在的举动中创立工具，创立者必需挪用ObjectContext工具中的CreateInstance函数。
正如所想像的，这会招致大批的凌乱，MTS的开辟者必需意想到逻辑举动的界限，而且得当地利用尺度的工具创立手艺(CreateObjectorCoCreateInstanceEX)大概ObjectContext工具的CreateInstance函数。
利用COM+，仍旧能主动地创立举动，可是举动的创立是经由过程利用组件的Synchronization属性来把持的，而不是基于怎样实例化一个组件。实践上，ObjectContext工具的CreateInstance函数如今的功效与尺度的工具创立手艺不异，而且它仅撑持MTS的向后兼容性。别的，COM+供应激活举动内部的工具的才能。如许可制止创立举动的分外开支和大概的挪用堵塞，为频仍利用的非事件性“工具”范例的组件提拔功能。假如必要，能够完成它们本人的锁定手艺。
同TransactionSupport属性一样Synchronization属性在组件服务扫瞄器中的组件Properties对话框设置，如9-8所示。
对Synchronization属性有五种大概的值：
?克制(Disabled)当组件的Synchronization属性设置为Disabled时，COM+将完整地疏忽组件的同步请求。正如当TransactionSupport属性设置为Disabled时，COM+将起首试图在创立者的情况中激活工具。假如创立者的情况有效或不相容，COM+将在一个新的情况中激活工具。假如工具承继创立者的情况，则工具能够分享创立者的举动，反之不克不及。应当在非事件性组件中利用这类设置，不管什么时候，应只管制止创立情况和举动的分外开支。
?不撑持(NotSupported)当组件的Synchronization属性设置为NotSupported时，工具的情况将不存在于举动中。但是，Synchronization属性为NotSupported的工具老是在一个新的情况中被激活。
?撑持(Supported)当组件的Synchronization属性设置为Supported时，工具的情况是不是存在于举动中依附于创立者的情况是不是存在于举动中。但是，具有这类设置的组件不必要举动，并且在没有举动的情形也能很好地实行。
?必要(Required)当组件的Synchronization属性设置为Required时，工具的情况将老是存在于举动中。假如创立者情况存在于举动中，则新的工具将在创立者的举动中激活。不然，COM+将在位于新举动中的新情况里激活工具。
?必要新建(RequiresNew)当组件的Synchronization属性设置为RequiresNew时，工具的情况将老是在新的举动中创立，不论创立者的情况的同步形态怎样。
正如你所看到的，Synchronization属性的选项和TransactionSupport属性的选项十分类似。但是，某些Synchronization选项依附于其他组件属性的某些值。出格是，撑持JIT激活的组件或TransactionSupport属性为Supported、Required和RequiresNew的组件必需在举动中被激活，并且必要Synchronization属性为Required或RequiresNew。只要当JIT激活被封闭而且TransactionSupport属性设置为Disabled或NotSupported时，Synchronization属性才干设置为Disabled或NotSupported。我们将鄙人一节更多地会商事件与举动的干系。
假如以为一切这些设置选项听起来有些使人狐疑，不用忧虑。Microsoft意料到这些相互依附的设置选项会使开辟者影象凌乱，他们在组件服务扫瞄器中创建考证功效。假如改动JIT激活撑持大概改动对Synchronization属性不相容的某些TransactionSupport属性，组件服务扫瞄器器将用告诫动静提醒并主动地调剂Synchronization属性来反应任何变更。告诫动静如9-9所示。
关于举动，最好的长处是它们全体经由过程COM+在幕后实行，组件不必要做任何附加事情，COM+供应了主动的并行和同步服务。别的，对非事件性组件供应了克制创立举动的功效。只管云云，了解Synchronization属性变更的感化和举动与情况在幕后怎样运转是很主要的，如许才干计划出高效和可扩大的组件。如今我们对事件性COM+组件的可设置属性有了必定的懂得，上面会商事件的保存期的每阶段。
19.3.3事件的保存期
COM+事件保存期可分为四个阶段，分离是：
?事件入手下手。
?创建并征募与ResourceManager的毗连。
?在事件中实行操纵。
?输入事件了局并停止。
主要的是记着只要TransactionSupport属性不是Disabled或NotSupported时组件才必要介入事件。COM+组件一样能可选地表决事件的了局。
上面具体看一下在单个和多个工具的COM+事件中，事件保存期的每阶段的详细情形。
1.事件入手下手
利用COM+事件模子，组件不会显式地启动一个COM+事件。相反，COM+在两种情形下主动地创立一个新的COM+事件：
?TransactionSupport属性为Required的组件由非事件性的客户激活。
?TransactionSupport属性为RequiresNew的组件由任何客户激活。
一个COM+事件由两部分构成：
?逻辑事件。
?物理事件。
逻辑事件也称为事件流，是共享一个物理事件的工具的一个逻辑汇合或逻辑组。另外一方面，物理事件是基础的MSDTC事件，利用两阶段提交协定，依据数据源和谐事件了局。当物理事件由COM+创立时，它利用第一流其余断绝(可串行的)创立，而且在组件服务扫瞄器中指定事件超工夫隔。COM+从基础的物理事件中完整地笼统工具，而不是让我们经由过程逻辑事件流和每一个工具的情况办理事件。
只管逻辑事件能够由几个COM+工具构成，可是事件流(逻辑事件)与物理事件一直存在逐一对应干系，这一点十分主要。
在事件流中创立的第一个工具，称为事件的根。事件的根可以经由过程实例化组件在统一事件中可选择地征募其他的COM+工具，这些被实例化的COM+组件的TransactionSupport属性为Required大概Supported。在这统一事件中创立工具时，COM+主动地将根工具的情况事件信息复制到新的工具情况中，因而COM+能在事件中保持一切工具之间的联系关系。事件信息包括一个称为TransactionID的GUID值，COM+用它辨认物理(MSDTC)事件。工具之间的干系如9-10所示。
将被征募到创立者的事件中的新工具必需在不异的举动中创立。使用MTS，这意味着根工具必需利用ObjectContext工具的CreateInstance办法创立子工具。如今COM+已使MTS和COM编程模子成为一体，不再必要CreateInstame办法，子工具能用VisualBasic中的CreateObject函数或VisualC++中的CoCreateInstance函数创立。
COM+事件从不超过举动，但举动与COM+事件不老是逐一对应的干系。单个举动大概会有几个COM+事件。假如一个COM+工具实例化一个TransactionSupport属性为RequiresNew的COM+组件，这个新的工具将在统一举动中，可是在分歧的COM+事件中，这个事件完整自力于创立者的事件。事件之间的干系如9-11所示。
一般由COM+运转期主动创立物理和逻辑事件，COM+也同意开辟者在已存在的MSDTC(物理的)事件中创立COM+工具。这个特性被得当地称为“带着本人的事件”(BringYourOwnTransaction，BYOT)。开辟事件性组件时，这个特性给开辟者供应了更多的天真性，同时仍旧能使用COM+的复杂性和逻辑事件模子。有了BYOT，组件能无效地使用MSDTC和COM+编程模子的组合来假造地完成任何事件义务。BYOT的典范用处是创立具有分歧属性的MSDTC事件，比方低于可串行化的断绝级别，然后在物理事件中创立一个或更多的COM+组件。
2.创建与ResourceManager的毗连
创立了逻辑事件和基础的MSDTC(物理的)事件后，COM+必需确保一切由C++工具实行的对数据源的数据修正操纵在MSDTC(物理的)事件中实行。每一个数据源的每一个毗连必需从征募到或注册到MSDTC事件。
一旦如许做了，一切的操纵都经由过程此毗连实行并由MSDTC监控。固然对每一个毗连的全部征募历程由COM+在幕后完成，可是必需分明在事件的全部保存期中怎样完成这一主要步骤的细节。
ResourceManager(RM)是数据库服务器的一部分，它利用COM+办理耐久的数据。因而对特定的数据源的毗连现实上仅是对ResourceManager的毗连。可是，COM+事件模子在散布式的事件系统布局中增添一个软件层，称为ResourceDispenser(RD)。
不要把ResourceManager和ResourceDispenser搅浑，他们是在COM+事件模子顶用于分歧目标的两个分歧的软件组件。
ResourceManager是一个复杂的体系服务。比方数据库体系，它在散布式事件中办理着耐久性资本。
MSDTC使用ResourceManager和谐事件的提交和回滚，这经由过程利用两阶段提交协定完成。ResourceManager的例子包含：SQLServer，Oracle和MSMQ等。
另外一方面，ResourceManager是一个历程内的静态链接库，它办理存进ResourceManager的内存中的非耐久的或一时的资本。比方数据源毗连、收集毗连、线程和内存数据块等。在体系呈现妨碍时不必要回护这些共享资本。
ResourceManager能办理可再用资本的缓冲池，在事件中主动地征募或注册他们，为COM+工具供应针对这些资本的操纵办法和接口。一个由ResourceManager办理的最一般的非耐久性资本是与把持永世性存储的底层ResourceManager的毗连。
不要让ResourceManager这个术语利诱了。ResourceManager和用于会见资本的组件是一样的。比方，OLEDB服务组件老是驻留在利用ADO或OLEDB的客户使用程序大概工具与OLEDB供应者及数据源之间。COM+指定OLEDB服务组件作为ResourceManager，将数据
源作为ResourceManager。其干系如9-12所示。
后面早已提到，作为ResourceManager，这些软件组件卖力办理非耐久的资本。可是它们也能可选择地供应两个主要的服务：
?资本缓冲资本缓冲是经由过程给COM+工具供应一个再轮回的资本而不是创立新的资本，供应了一个无效地分派非耐久性资本的办法。COM+工具利用完资本后，将资本放回缓冲池中，如许它或其他的COM+工具能够立即再利用这些资本。
到数据源(ResourceManager)的毗连是所利用的非耐久资本中最一般的一个。创立和作废一个到ResourceManager的毗连是一个“高贵”的历程。为了无效地给COM+工具供应数据源毗连，ODBC驱动程序办理器和OLEDB服务组件都供应ResourceManager毗连的缓冲，高贵资本的重用或轮回抵消耗这类资本的COM+工具或使用是完整通明的。
?事件征募事件征募(enlistment)是联系关系或征募具有MSDTC(物理的)事件的ResourceDispenser的毗连的历程。一旦完成事件征募，一切的事情由COM+工具经由过程此毗连实行，而且由MSDTC监督并在散布式的事件中失掉回护。一切的操纵将作为单一的事情单位实行，事件作为一个全体必要断定其ACID属性。当逻辑事件完成时，MSDTC对一切介入的ResourceManager实行两阶段提交协定。事件征募是完整可选的，ResourceDispenser决意是不是在以后事件中征募资本。事件征募经由过程简化事件性COM+组件的开辟在COM+事件中起侧重要感化。
COM+经由过程对组件埋没散布式事件庞大的细节来完成义务。现实上，在事件性命期的此阶段中，独一要做的是创建与数据源的毗连，就像寻常利用ADO、OLEDB和ODBC一样。COM+和ResourceDispenser卖力实行资本缓冲和事件征募。
3.实行操纵
一旦创建数据库毗连，COM+工具能依托ResourceManager入手下手实行操纵。
当ResourceManager吸收和处置这些数据时，能接纳响应的办法确保事件满意ACID请求。很多ResourceManager完成一个日记机制，供应回滚未提交的变更的才能，满意原子性的请求。经由过程再使用或恢复未意料成绩引发的变更，日记机制也同意ResourceManager确保事件的耐久性。锁用于断绝事件的变更，使其他针对统一ResourceManager的事件不受这些变更的影响。为确保分歧性，ResourceManager一般界说特别的机制或划定规矩回护数据的完全性。
4.表决事件的了局
后面已提到，事件性COM+工具的情况包括称为TransactionID的GUID值，它用于在事件中联系关系多个工具，并将逻辑事件链接究竟层的物理事件。但是，这仅是存储在工具情况中的部分信息。事件工具的情况也包括两个其他的主要信息，它们用于完成事件，表决事件是提交仍是停止。这两部分信息是：
?完成标记(DoneBit)DoneBit是个布尔值，标明工具是不是应当生效，TURE值显现工具已完成它的事情，且能够生效，FALSE(缺省)值标明工具不克不及生效。
在办法挪用完成之前，COM+不检测DoneBit的值。因而，DoneBit值能改动很多次，它的值在办法挪用以后才成心义。DoneBit现实上是由JIT激活供应的，以是，可用与非事件性组件不异的办法撑持JIT激活。
?分歧性标记(ConsistencyBit)ConsistencyBit偶然称为“HappyBit”，它是一个布尔值，它显现COM+工具决意是提交仍是停止事件。TURE值显现工具试图提交事件，FALSE值显现工具要强制停止事件。
工具生效(DoneBit设置为TURE)后，ConsistencyBit才由COM+用于判别。因而，ConsistencyBit值能够反复地修正，乃至在分歧的办法挪用中也能够修正，由于只要工具生效前的最初值才是事件表决要用的。COM+用TURE值初始化ConsistencyBit，即COM+假定事件是想提交的。
DoneBit和ConsistencyBit与事件的干系如9-13所示。
当事件的根生效时(根工具的情况的DoneBit设置为TURE)，COM+在事件流中对每一个情况的ConsistencyBit赋值，来决意事件了局。试图提交事件的决意是定见分歧的决意。
假如在事件中一切工具设置它们的情况的ConsistencyBit为TURE，表决妄图提交事件，则在事件中实行的一切操纵妄图举行永世性的提交。但是，假如事件中任何工具设置它的情况的ConsistencyBit为FALSE，表决停止事件，则在事件中完成的一切操纵将被回滚。当这两种情况的任一种产生时，COM+挪用加入MSDTC，提交或停止这个物理事件。MSDTC然后经由过程利用两阶段提交协定卖力与一切征募的ResourceManager和谐散布式事件的提交或停止历程。
表19-2概述了DoneBit和ConsistencyBit对COM+事件的了局的影响。
我们懂得了DoneBit和ConsistencyBit取甚么值可以提交或停止COM+事件。上面先容怎样检索和修正它们的值。
ObjectContext(或IObjectContext)接口的办法多是编程把持COM+事件了局的最简单的体例，由于这类体例同意挪用单个办法同时设置DoneBit和ConsistencyBit。因为DoneBit和ConsistencyBit之间有四种大概的组合，以是存在由ObjectContext接口界说的四个办法，它们分离是：SetComplete、SetAbort、EnableCommit和DisableCommit。
如表19-3所示，每个工具情况的办法合绝对应。与DoneBit和ConsistencyBit值的一个共同组合绝对应。
(1)SetComplete办法
SetComplete办法告知COM+，一个特定的事情单位已乐成地完成。经由过程设置DoneBit和ConsistencyBit都为TURE，SetComplete办法强制工具作废激活并表决要提交事件。只要在根工具中挪用SetComplete办法时，COM+才将在每一个工具的情况中反省ConsistencyBit以决意事件了局。以下代码例子展现了怎样挪用SetComplete办法：
(2)SetAbort办法
SetAbort办法告知COM+，工具没有乐成地完成它的事情，它想停止事件。假如一个或多个的COM+工具在事件中挪用SetAbort办法，因为SetAbort办法设置了ConsistencyBit为FALSE且DoneBit为TURE，全部事件将停止。
(3)EnableCommit办法
EnableCommit办法告知COM+，工具能提交事件，但工具还没有被作废激活。EnableCommit办法经由过程设置ConsistencyBit为TURE且DoneBit为FALSE完成这一义务。
(4)DisableCommit办法
DisableCommit办法恰好与EnableCommit办法相反。DisableCommit办法告知COM+，工具的事情没有完成，事件不克不及在以后提交，工具也不想作废激活。DisableCommit办法设置工具情况的ConsistencyBit和DoneBit都为FALSE。因为工具仍旧激活，在办法挪用之间将坚持其形态：
(5)停止事件的其他体例
年夜多半情形下，能经由过程ObjectContext接口显式地把持事件了局，但另有别的两种体例能停止COM+事件：
?事件超时(TransactionTimeout)假如在事件中凌驾事件设置的超工夫隔值仍没有举动，则停止以后事件。当一个事件超不时，它将主动地停止。默许超工夫隔值是60秒。在组件服务扫瞄器中，这个值能在组件Properties对话框的Options选项卡中改动。假如你正调试事件性COM+工具，很分明必要增添事件超工夫隔，以便有充足的工夫在COM+工具中单步伐试办法挪用，确保事件没有主动停止。
?客户开释一切对事件根的援用当客户开释对根工具的最初一个援用时，COM+隐含地试图提交该事件。隐含的事件提交历程一般应当被制止，由于这会引发主机呈现成绩。
隐含提交的一个成绩是事件的了局不会关照给客户。当根工具挪用SetComplete办法时，COM+试图在把把持前往给挪用者之条件交该事件。假如提交事件时呈现毛病，COM+只是复杂地向客户端发送一个毛病动静。这同意客户使用程序很好地处置成绩而且大概再次试着举行事件处置。但是，因为隐含提交时客户端不再与根工具毗连，因而假如不克不及提交事件，客户端就不克不及吸收毛病信息。客户完整不晓得事件的了局。
隐含的事件提交历程还使得事件保存期比需要的工夫长一些。当事件存在时，它坚持着对资本的锁，以确保ACID特征的断绝请求。一个翻开的、非举动的事件能制止其他事件在这个资本上实行操纵。这能引发功能瓶颈，严峻限定了使用程序的可扩大性。一个更好的办法是挪用ObjectContext的办法，显式地提交或停止事件。
5.事件保存期小结
事件在它的保存期中履历的全部历程听起来很庞大，主要的是记着，对介入事件的COM+组件的独一请求是给它们设置响应的TransactionSupport属性。有很多分歧的手艺为提交或停止一个事件供应了天真性，只管如今了解它们另有一点坚苦，但它们使得开辟基于组件的事件性体系更简单。
19.3.4事件会见自界说资本
怎样对没有供应ResourceDispenser的资本举行事件性会见？是不是必要开辟一个自界说的ResourceDispenser和ResourceManager？假如利用COM+，则甚么都不必要。
COM+供应了一个新的特征，称为抵偿资本办理器(CompensatingResourceManager，CRM)，它供应了一个基本布局来加强COM+对事件处置的撑持才能。
CompensatingResourceManager供应了一个复杂的办法，同意非事件性的资本介入由MSDTC办理的事件。
在仍旧利用MSDTC来和谐事件时，CRM是开辟一个庞大的COM+ResourceManager和ResourceDispenser的一个更复杂的选择。比方，能开辟CRM对诸如文件体系、内存或Windows2000注册表等资本供应事件性会见。事件性的COM+组件能经由过程CRM的接口会见这
些资本，而且由CRM实行的一切操纵都由一个MSDTC事件举行回护。
别的，由于利用MSDTC作为COM+ResourceManager/Dispenser和CompensatingResourceManager的事件和谐器，以是一个单一的事件能够由一些针对资本的操纵构成，这些资本能够是上述的恣意布局。这个特征使CompensatingResourceManager成为能供应对资本的事件性会见的最具有吸引力的办理计划之一。
asp可以轻松地实现对页面内容的动态控制，根据不同的浏览者，显示不同的页面内容。而浏览者一点觉察不出来，就像为他专门制作的页面一样。使用各种各样的组件，asp可以完成无比强大的功能。 |
|
|Archiver|手机版|仓酷云
鄂ICP备14007578号-2
发表于 2015-1-16 22:54:55
收藏
转播
分享
淘帖
顶
踩
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
楼主