Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Lessons Learned in Enterprise Design and VB6 : Page 3

In this article you will be presented with a number of tips taken from lessons that the author has learned after a couple of years working with COM+, VB6 and SQL Server.


advertisement

#8: Autocomplete Is Great
In my article "Example of code structure for COM+ component" I showed a code structure for methods in COM+ components. As a matter of fact, this code structure was also completely compatible with MTS components. Sooner or later, the time comes to cut off this compatibility. When it does, AutoComplete (or "Automatically deactivate this object when this method returns" as it is called in the Component Services Explorer) could be declared for methods of transactional components in COM+. Due to this there is no need for calling SetComplete/SetAbort, because COM+ will deal with it for you.

There is also little reason for me to use a module-level variable for keeping the ObjectContext. I use GetObjectContext instead when I need the ObjectContext. This, together with AutoComplete, helps to simplify the code structure enormously. Keep watching VB-2-The-Max in the coming weeks, because you will soon find an article where my updated code structure is discussed more in detail.

#9: Use "Must Be Activated in Caller’s Context"
As you probably know, COM+ lets your instances live in contexts and COM+ uses the context border as the place for adding interception. That is, when a call to your instance passes the context border, COM+ can intercept the call and do stuff before the call moves on to your component and at the return from the method. This is a great model, but as always, there are drawbacks too, the most obvious one being overhead. Each context takes quite a lot of memory, and interception eats CPU-cycles. When you benefit from services, this is just fine, but when you have components that don’t need services it is a waste of resources.



In these cases you should check "Must be activated in caller’s context." This means that if an instance of this object can’t locate in the caller’s context, you will get an error message. Otherwise the caller and the new instance will share a context and there is no interception between those instances. You have also saved the memory of one context.

In order to succeed with the co-location, your component with "Must be activated in caller’s context" has to follow some rules. It must satisfy the following:

  • Disabled COM+ transactions
  • Disabled JIT
  • Disabled synchronization
  • Disabled events and statistics

And the application may not use component-level security. (Because of the last reason, those components will often be put in a separate Library application.)

If you make a quick and dirty test, you will see that the instantiation time for "co-located" components are much lower, but it’s not often that you create thousands of instances of a component, so I didn’t use to think this would make much of a difference in real-world applications. That was before I was invited to a brainstorming meeting for increasing throughput of a certain use case. When we re-configured some components so they could "co-locate," the throughput increased fourfold!

#10: Some Scripts Are Good
Each and every time I work with ASP, I hate the script nature of it. Saying that, there are other types of scripts that I find good. The example I’m thinking about is letting your components generate a T-SQL script with several calls to stored procedures and then this script is sent to SQL Server for execution in one single roundtrip. Automatically generated scripts like these are great!

If you decide to use this methodology, you will have to watch out that you don’t fall into the trap of too many string concatenations in VB6. (In Visual Basic .NET, the StringBuilder class is terrific here.)

If you use this script technique, you will also solve the problem of using local T-SQL transactions. Most often I let the stored procedures control the transactions, but when a transaction has to span several stored procedures, my script solution comes in as a neat solution.

#11: Control Transactions from the "First" COM+ Layer
In the past I have decided to control transactions in the last layer before I hit the database. (I call that layer the Persistence Access layer, but a more common name for it is the Data Access layer.) The idea was to get as short transactions as possible and it works very well. The main problem is that it gives huge effects on design. It means that I have to ensure that all the data is sent to the method in the Persistence Access layer in one go. That often makes the design of previous layers less natural and means that I always need a controller in the Persistence Access layer that can receive all the data, and then distribute it to primitive methods.

The solution to the problem is to let the first COM+ layer control the transactions instead. I call that layer the Application layer, and I have one class in the Application layer per use case. As a matter of fact, in my opinion transactions are an integral part of use cases. Oops, won’t that mean getting longer transactions and longer lock periods? A catastrophe is coming Nope, when I use my script solution (discussed in #10), I actually only gather information to the script during the complete use case and when I’m ready to send the script to the database, it’s not until then the physical transaction is started and the locks are taken. It’s the same with both COM+ transactions and local T-SQL transactions. A better design, with as short transactions as before.

I have now presented several tips from lessons learned from a couple of years of work with COM+, VB6 and SQL Server. Hopefully you have found the tips useful.





Jimmy Nilsson is the owner of the Swedish consultant company JNSK AB (www.jnsk.se). He has been working with system development since late 1988 (with VB since version 1.0) and, in recent years, he has specialized in component-based development, mostly in the Microsoft environment. He has also been developing and presenting courses in database design, object-oriented design, etc. at a Swedish University for six years. Jimmy is the author of ".NET Enterprise Design with Visual Basic .NET and SQL Server 2000" and he often speaks at VSLive conferences.
Comment and Contribute

 

 

 

 

 


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

 

 

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