1<object>?" and "What benefits can I reap by using the @TRANSACTION directive in an ASP page?" The Active Server Pages runtime was originally engineered as an in-process server loaded into the process space ofInternet Information Server (inetinfo.exe). Prior to MTS, COM developers deploying server-side components sometimes used inetinfo.exe as a surrogate process. This led to numerous performance problems and a lack of fault tolerance in web applications. When IIS 4.0 was introduced, it promised fault tolerance by allowing ASP to run in its own isolated process. In order to make this possible, an additional layer of abstraction was placed on top of ASP. This layer, which is implemented as a COM object running inside MTS is known as a Web Application Manager (WAM) component. A common paradigm found in COM and MTS is the introduction of a level of indirection as an instrument of functionality. Other examples of this use of indirection are the concept of interception in MTS and the use of class objects in classical COM. The WAM component provides a level of indirection that shields ASP developers from the internal gears of MTS. When an ASP application is created, the system simultaneously creates a WAM component, which is initially registered in MTS as a library package, meaning that it will be packaged as a .DLL rather than a separate process. Under this scenario, running the ASP application allows the ASP intrinsic objects (Request, Response, etc.) to be created in the same process as IIS. Fault tolerance can be introduced simply by changing the "Run in separate process" attribute in the properties page of the desired web application. It is important to note at this point that WAM components do not actually execute ASP code. Instead, each WAM component relies on the assistance of a Page object. It is the Page object, which acts as an abstraction to the physical ASP page, which is responsible for executing server-side code in the MTS environment. With the release of MTS, Microsoft introduced a new concurrency model known as the activity, which satisfies the ACID transaction requirements. An activity represents a group of objects created on behalf of a single base client. In a client/server application this concept is easy to grasp. A forms-based MFC or Visual Basic front-end calls objects residing in MTS packages in another process. When an Active Server Page, and hence the Page object, becomes the client, things get a little more confusing. A direct benefit of the IIS/MTS integration model is the fact that a Page object can act as the root object of a transaction. In order to accomplish this, simply place an ASP directive with the transaction attribute at the top of the ASP page, for example:   
2  

 1  
 2When an ASP page is requested that contains this attribute, the Page object will serve as the root of the transaction and thus control its ultimate outcome. Understanding this basic architecture can answer such simple questions as the common "What is the difference between Server.CreateObject and CreateObject?" Because the Page object in an ASP page acts as the root of an activity in MTS, a call to Server.CreateObject is analogous to ObjectContext.CreateInstance. In addition, this call marshals the ASP intrinsic objects to MTS. Calling CreateObject API directly will ignore the context that the page is running in and will result in the creation of an additional activity. In other words, CreateObject will result in a call to CoCreateInstance rather than a call to ObjectContext.CreateInstance.   
 3  
 4This causes the following problems:   
 5  
 61\. ASP will be unaware of the objects created.   
 7  
 82\. The deprecated OnStartPage/OnEndPage methods will not be called.   
 9  
103\. ASP will be unaware of the threading model of the created objects.   
11  
12So should you use transactional pages? There is obviously no single answer to that question. It depends on your application architecture and what you are trying to accomplish. However, keep these tips in mind when using transactional pages:   
13  
141\. Transaction control is much greater when using a classical COM component.   
15  
162\. Active Server Pages are still considered part of the presentation layer in an n-tier application, and assuch, all business logic should reside in COM components.   
17  
18  
19\---------------------------------------------------------------   
20  
21http://blogs.msdn.com/ericlippert/archive/2004/06/01/145686.aspx   
22\---------------------------------------------------------------   
23  
24来翻译一下   
25千万别使用CreateObject   
26  
27Server.Createobject和CreateObject到底有啥区别呢?看起来，两者换着使应该问题不大,但实际上如果你使用错了的话，会使你的ASP程序出大问题.   
28  
29VBS里的CreateObject是在脚本引擎的上下文环境里创建的对象实例,而不是在当前正在执行的ASP页面的上下文环境里.在单机的时候,这个方法没有什么问题,但是在一个web server上,它不仅阻止了对asp页面内部属性和值的访问,而且还没有使用Server.CreateObject时所能拥有的内存管理和进程独立功能   
30  
31当使用asp页面时,我们实际上还未发现CreateObject对于Server.CreateObject的任何很明显的优点.所以，请务必在您要使用createobject的时候使用server.createobject   
32\-------------------------------</object>