Browse DevX
Sign up for e-mail newsletters from DevX


Building a Better Mousetrap for COM+ (MTS) : Page 3

Michael Long shares his insight into improving the MTS Bank Sample for use under COM+. The article discusses issues with the original sample project, the changes made to improve the code, and why the changes were made. It also covers code flow related to error handling, and the impact of an active error handler on the On Error... statement. The code demonstrates techniques that are sure to improve the stability of your COM+ (MTS) components. In addition, these techniques can lead to increased scalability by helping you minimize resource leaks in the middle-tier. A must read for the VB developer looking for ways to improve his MTS development skills, or seeking to better understand error handling in VB.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

ADO Variable Declarations and Instantiation

The ADO object declarations with "As New" in the original code caught my eye. This is not only a bad practice for ADO, but for declaring objects in general. Using "Dim .. As New .." incurs additional processing every time that the object is referenced, creating the object if it does not exist. A more efficient approach is to use "Dim As ..", and instantiate the object in the procedure body.

Example of ADO object declaration and instantiation:

  Dim cn As ADODB.Connection

  ' preferred instantiation using New keyword;
  ' should be used in VB
  Set cn = New ADODB.Connection

  ' alternate instantiation using CreateObject;
  ' should *only* be used in scripting languages
  ' (such as ASP)
  Set cn = CreateObject("ADODB.Connection")

  ' instantiation via the context should *never*
  ' be performed (even under MTS 2.0)
  Set cn = GetObjectContext.CreateInstance("ADODB.Connection")

I included the latter method of instantiation because this is discussed in the newsgroups on a weekly basis. I am aware that there are MSKB articles and a number of books by noted authors that use this technique. However, any document that demonstrates this type of code simply demonstrates that the author was remiss in his research at the time of publication, as ADO is not MTS aware.

Just because you see it in print doesn't mean it is accurate. Remember that there is an "ex" in expert, and humans have been known to make mistakes (I know I certainly have). My advice - question what you read, and write code samples to validate any point that you are unsure of. Simply mimicking code written by others does not lead to an understanding of the technology.

Avoiding Duplicate Constant Declarations

This is a rather trivial point to correct, as it simply required moving common declarations to a utility module and changing the scope from Private to Public. What raises my ire (and I am part Irish) is that the practice of duplicate declarations goes hand in glove with failing to write procedures to handle commonly performed sequences.

As all experienced developers know, duplication of code leads to long-term maintenance problems. Inevitably, a change will be made in one module that does not get fully propagated and a new bug will result. With adequate testing it will be caught before deployment, but the catch, fix, retest and release cycle still adds cost to the project.

I would contend that Microsoft should not publish sample code that demonstrates poor coding practices. This leads to a longer learning cycle for Johnny Newbie (we've all been there), lowers productivity, and increases software development costs. I do not expect bug free samples, but simply that the author demonstrate basic proficiency with the language of implementation.

Implementing Interfaces

Rather than modify the source code to the client application extensively, I chose to implement the interfaces exposed by the Sample Bank Account (VC version) Type Library (account.tlb). This required only minor changes to OPBank, but immediately allowed the VB objects to be instantiated. However, implementing the "immutable" interface exposed via the type library presents a problem for scripting languages, as they cannot detect the interface. To get around this issue, I simply exposed public methods that wrap the private methods.

Example of implementing an interface and exposing scripting compatible methods:

' must add account.tlb to project references
Implements CUpdateReceipt

' exposed for scripting language compatibility
Public Function Update() As Long
  Update = CUpdateReceipt_Update()
End Function

' implements the method for the "immutable" interface
Private Function CUpdateReceipt_Update() As Long
  ' code body removed for brevity
End Function

As I previously indicated, this feature was not an omission on the part of the original author. The choice to modify the code in this manner was due to personal preference, as I found it to be the shortest path to my goal - which was benchmarking comparable objects written in VB, Delphi, and VC++. These objects were used in a previous article published at vb2themax.


By taking a sample project and explaining both the original problems (as I saw them) and the actions taken to correct the deficiencies, I hope to eliminate some confusion for COM+ (MTS) developers that have yet to master the tools and technologies. I am active in the MTS and COM+ related newsgroups, and see the confusion and misinformation that plagues this topic.

On behalf of myself, Jimmy Nilsson and Enrico Sabbadin (as I'm sure I speak for them as well), I wish to express our most sincere thanks to Francesco Balena for allowing access to this forum. While the newsgroups are a good forum for discussion, the value of an individual's contribution is greatly diminished because of the transient nature of the posts. Participants often miss out on relevant discussions, and many topics are rehashed all too often - sometimes several times per week.


[1] Platform SDK - OPBankSample
     \Program Files\Platform SDK\Samples\COM \Services\Object_Pooling\
[2] Platform SDK - Account.VB
     \Program Files\Platform SDK\Samples\MTS_Only\Installation_Verification \
[3] Q170156 - INFO: VB 6.0 Readme Part 12: Transaction Server (MTS) Issues
[4] Developing a Visual Basic Component for IIS/MTS, June 1998
     by Troy Cambra, Support Engineer, Microsoft Corporation
[5] Q250309 - INFO: Do Not Use ObjectContext in Class_Initialize and Class_Terminate Events
[6] Q259382 - INFO: Microsoft Transaction Server (MTS) Knowledge Base Article Index


Michael Long currently works as a Senior Developer with Hampton-Tilley Associates where he specializes in the design and implementation of n-tier applications utilizing Oracle and SQL Server databases. He has been working with Visual Basic and Visual C++ since the introduction of both as 1.0 products, and primarily developing multi-tier applications that utilize distributed processing and data replication for the past six years. Michael is currently interested in research related to maximizing both the scalability and performance of applications based on the Windows DNA framework, and frequently shares his expertise in the newsgroups. For more info: http://extremedna.homestead.com
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date