This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

Working with MTS, ASP, and Visual Basic

Ken Spencer

Code for this article:Serving0400.exe (34KB)

T here are lots of potential roadblocks to deal with when creating an application. The more pieces you need to put together, the truer this becomes. When building a high-performance Web application, you usually put together many technologies and components, such as ASP, Visual Basic®, COM, and Microsoft® Transaction Services (MTS), plus a database and even XML. Using these technologies together can lead to many complex questions.       This month, I�m going to dive into the programming side of MTS so you can better understand what can and can�t be done in your Web applications. This column is built from some recent experiences I have had with MTS and the research that those experiences led me to conduct. Back to Basics       When you�re using MTS with Visual Basic, the first thing you usually do with a component that you�ve written is compile it and drop it into an MTS package. You can put the component into the MTS package by dropping it into the Packages Components folder using Windows® Explorer. Then you can open the properties for the component and set its transaction type. This has been covered in lots of articles, so I won�t belabor the point. Basically, you just drop the component in and it runs in MTS. Pretty simple, so far.       Since most of you are calling MTS components from ASP scripts, you may be using MTS features in your ASP code. You can make your ASP script transactional and have it participate in the transactions with the COM objects it calls, or you can do all the database work in the COM objects and let your ASP script work as it normally does without worrying about transactions. ASP works best with transactions if MTS and Internet Information Services are on the same box. Each transaction requires two calls to the MTS box, and this doesn�t scale well.       In order to make an ASP script transactional, add the @TRANSACTION directive to the top of the page. When you declare a page transactional, any script commands and objects used on the page are run under the same transaction context. MTS handles the details of creating the transaction and determining whether the transaction succeeds (commits) or fails (aborts). An ASP script transaction cannot span multiple ASP pages. If a transaction requires objects from several transactional components, you should group operations that use those objects into one ASP page.       There are two MTS methods you can call in your ASP script: SetComplete and Abort. SetComplete declares that the script is not aware of any reason for the transaction not to complete. If all components participating in the transaction also call SetComplete, the transaction will complete. The SetAbort method declares that the transaction initiated by the script has not completed or has had a failure and should not be committed. Transactions complete automatically when the script in a page finishes its execution. If SetAbort is executed in a page, this will terminate the transaction and cause it to fail. The ASP application does not need to call either of these statements. If it doesn�t, then the transaction will either complete successfully or will abort when the entire page finishes processing. Calling either statement can, of course, change this outcome.       Your ASP script can also respond to the firing of two MTS events: OnTransactionCommit and OnTransactionAbort. The former fires when the transaction is committed, while the latter fires when the transaction aborts.       Now, what happens when you call your MTS COM component from the ASP page? Well, the MTS component may execute in the same transaction as the ASP page, or it may not. How�s that? If you have the transaction support property of the component set to "Requires a transaction" or "Supports transactions," then the component will run in the same transaction context as the ASP page. If you have the transaction support property set to "Requires new transaction," then the component will run in its own transaction. In short, use care when setting the transaction support property to make sure the component does what you want.       You can do several things to your component to make it work more effectively with MTS. First, you should create a project reference in your Visual Basic project to the Microsoft Transaction Services Type Library. Then, you can begin to modify your code. Next, open each class module that will have MTS support. You can set the MTSTransactionMode property of the class to the type of transaction support you require. This puts the property directly in the compiled component and locks it in. If you move the component to a different server, this property will always retain this setting. This step is highly recommended.       Next, you can begin to add support for MTS directly to the class. You really need three things. First, when your code is going to do any work and return (as in a function call that updates a database), you should let MTS know what is going on. You do this by gaining access to the MTS context object:

Dim oContext As ObjectContext
set oContext = GetObjectContext()

Next, you can let MTS know that your code has completed and that things are OK:

oContext.SetComplete

If your code detects any type of problem, you can also let MTS know that it should abort the transaction:

oContext.SetAbort

      Most discussions of MTS stop here. But let�s explore what the two Setxxx methods are really doing. Neither of these statements causes MTS to perform an action. Instead, they simply mark the transaction as either successful or unsuccessful to that point. The transaction does not really complete until the root component (the component that started the transaction) completes.
      MTS handles the problem of object instantiation with two features called just-in-time (JIT) activation and as soon as possible (ASAP) deactivation. JIT activation means that objects that are created as required by the client load at any given time. When the object calls SetComplete, the server knows that the object doesn�t need to hold on to any state data and will deactivate the object ASAP. The server can then reclaim any resources the object held.
      In this way, the client can get a reference to the resource and hold it as long as possible while conserving server resources. When the client references any method or resource in the object again, MTS recreates the object. The newly instantiated object is different from the one the client last used, but MTS makes sure the client�s reference still works so that the client does not care that the object is different.
      You can call DisableCommit to suspend the committing of a transaction. This allows you to verify that a transaction isn�t committed between method calls to an object. Any attempt to commit the object before EnableCommit or SetComplete is called will abort the transaction. EnableCommit notifies MTS that while the work the method is doing is not yet complete, all work related to the currently executing transaction can be committed. This allows MTS to commit the transaction at the proper time.
      I still haven�t touched on the most interesting MTS method. Let�s discuss what happens when you create an instance of an object that is used by MTS. When a client application like an ASP script calls a method in an MTS object, it never directly receives an interface to that MTS object. The MTS Executive wraps every object, and the client gets an interface to the context wrapper. Once the method call has completed, the wrapper will release all interfaces to the object and it will destroy the object itself. The client never knows that it now has an interface to a deactivated object. The next time the client invokes a method on the object, the wrapper will create a new instance of the component to fulfill the request. This is how the JIT features work.
      This brings up a discussion I had at TechEd last year. One of the COM+ program managers was discussing how COM+ and MTS handled objects. He mentioned that because MTS was layered onto Windows NT® 4.0, MTS objects were sort of second-class COM citizens. This is why you need to use a method called CreateInstance to instantiate COM objects within an MTS object, instead of using CreateObject. CreateInstance allows the new object to inherit the current context object.
      If the newly created object is an MTS object executing within a transaction, any object that is created from the component�s context object will be enlisted in the current transaction automatically, under two conditions: the object to be created must be marked as either "Supports transactions" or "Requires a transaction."
      So, when you create an MTS object in your ASP script, you can use CreateObject. But when that object creates another object you should use CreateInstance.

Set oBook  = Context.CreateInstance("Pubs.Book")

This works just like CreateObject, except Book is now running in the same context as the object that initiated it. Note that the same program manager pointed out that CreateInstance will work in COM+, but it is no longer necessary.
      Another issue will come up when you try to pass around a pointer to an MTS object. There are often times when a client will require a reference to an object created from a secondary call within a method. Because MTS stores context information about each instance of an active object, it must be informed that a reference is being returned to a client.
      When a component wants to pass a self-reference to a client or to another object, it should always call SafeRef first and then pass the reference returned by this call. SafeRef is used by an object to obtain a reference to itself that can be passed safely outside its context. The syntax looks like this:

Set safeobject = SafeRef(Me)

From the April 2000 issue of MSDN Magazine.