Professional Active Server Pages 2.0

Professional Active Server Pages 2.0



Product Details

ISBN-13: 9781861001269
Publisher: Apress
Publication date: 03/03/1998
Series: Professional Ser.
Edition description: 1998
Pages: 991
Product dimensions: (w) x (h) x 0.08(d)

About the Author

Alex Fedorov is working as an executive editor for ComputerPress ,magazine - a monthly software and hardware magazine, published in Moscow, Russia. During his work in magazine Alex authored more that 150 articles on various programming topics, including Delphi programming, Internet programming, COM/OLE and other technologies. Alex is also the author of several books, published in russian.

Brian is a Senior Developer with NCR's Human Interface Technology Center in Atlanta, Georgia. At the HITC, Brian is responsible for prototyping and developing advanced applications that apply superior human interfaces as developed at the Center. His tools of choice include Visual Basic, Visual C++, Java, and all of the Microsoft Internet products. Brian has developed and deployed Multimedia Kiosk applications, Computer-based Training applications, and other advanced user interface prototypes for the past three years.

Richard is a Microsoft Certified Solution Developer and a senior consultant for a major global IT services company. He has recently been specialising in Microsoft Internet architectures and helping organisations to use these technologies to build mission critical Web solutions.

Shawn is currently an independent Internet developer and consultant working in the Los Angeles area where he is also studying architecture at the University of Southern California. He writes articles for IEWorld ( an on-line journal that is dedicated to the latest in Internet Development and Microsoft technologies. His experience in web technologies ranges from HTML to client and server-side code and web application development. He has alsoworked as a contractor for companies ranging from nursing homes to Microsoft's Internet Gaming Zone.

Robert Smith is a graduate of Oxford University who has been working for Anthony Cook Associates since 1994. He has been developing with Access since its first release in 1992. About half of his time is psent developing with Access and SQL Server and the remainder is spent on consultancy in client/server design and development issues.

David gained experience in BASIC, Pascal, COBOL and OCCAM, before joining a UNIX system house where he stayed for 4 years, becoming the chief UNIX/C guru. For the last 3 years he has been working for a Microsoft Solution Provider, specializing in Access, VB and SQL Server, as well as playing extensively with every Beta product that comes his way.

Read an Excerpt

From Chapter 13: Introducing Transactions

...Component Design Issues

Up to this point, we have examined the features of transaction processing systems and how they can be used to create more robust applications. Microsoft Transaction Server is a transaction processing system that has been integrated with IIS and ASP to provide a complete application development platform for both Internet and intranet applications. Now what we have an understanding of what a transaction processing system can do, we need to look at how to create the components of the applications that will be part of the transactional application.

The components of the application will be straightforward COM components. They can be developed using any development that will create COM objects. These tools include Visual C++, Java, Delphi, and Visual Basic.

In a later section, we will cover the differences in the components created by these tools when we examine the differences in the threading model.

There are several areas that we will cover that make developing MTS-friendly components different from developing regular COM components. These areas include how to hold state in an object, issues surrounding the various threading models, and the scope at which objects are visible. In fact, every COM components can work in an MTS environment. It is just by adding a few bits of code that a COM component can become MTS-friendly and thereby work much better.

Holding State

In developing, whether they are standard COM objects or COM enhanced to work better with MTS, an object can be one of two types. The two types are stateless and stateful. A stateless object doesnot retain any information from one method call to the next. A stateful object has some internal storage mechanism that allows it to retain information between two separate method calls.

An application designer can take advantage of either type of component in their application. The two types of components can even be mixed in one application. There may be times that it is more efficient from a coding standpoint to develop a component that holds state within the object. However, there are tradeoffs is using stateful components within the context of MTS.

Activation and Deactivation

As we discussed earlier in this chapter, MTS can manage the creation and utilization of components automatically. This allows applications to scale much more efficiently than using other means. To look at the effect that state has on this mechanism, we need to look at the deactivation of objects.

An object has two modes inside of MTS. When it is first created, it is deactivated. A deactivated object looks to the client as a real object, but it consumes very few resources on the server. Through a process known as just-in-time activation, MTS will activate the component when the client actually calls a method on the object. This allows the clients to not have to worry about when it should create an instance of an object in relation to when it is used. The client can create the instance and hold it as long as it wants before using it, as MTS will not create and activate the object until it is needed. This is similar in the ASP world to using the <OBJECT> tag to create an object instance rather than Server.CreateObject.

There are three ways that an object, once activated, can be deactivated. Deactivating an object is different from destroying it. The object can request deactivation through the ObjectContext interface by calling either SetComplete or SetAbort. If the object is participating in a transaction, and that transaction is completed. Finally, if all of the clients that are accessing the object release their references to the object, then it will be deactivated. When an object is deactivated, MTS can use the resources that were allocated to it for other objects. This means that any information that was stored inside of the object is lost. The recently deactivated object could also be recycled if MTS detects another client requesting the same object.

Stateful Objects

A stateful object is one that retains internal information from one method call to another. For an object to be able to do this, there are certain tradeoffs that must be made. As we said earlier, when an object deactivates, it loses all information that is stored inside of it. In order for an object to be stateful, it must maintain internal information, which ,means it cannot be deactivated. If a stateful object were to be deactivated, it would lose all of its state, thus becoming a stateless object.

When an object decides to become stateful, MTS no longer has the ability to use its resources for any other objects. An object will become "stateful" if it does not call SetComplete or SetAbort when it finishes its processing. The stateful object has in effect locked a portion of the resources that MTS has to work with. MTS relies on its ability to dynamically manage resources in order to allow applications to effectively scale. Therefore, if a system is using a large number of stateful objects, then it will be much less efficient when scaling.

This does not mean to say that you should never use stateful objects when developing MTS applications. As we stated earlier, the use of stateful objects can make the development of client applications much easier. It is just important for the developer to understand the implications that using stateful objects will have on the scalability of their application.

Threading Model

An important issue that the developer of MTS applications needs to consider is the threading model that is used by the components of the application. The threading model of a component determines how the methods of the component are assigned to threads in order to be executed. The MTS environment itself manages all of the threads associated with its applications. A component should never create any threads on its own. This is primarily of concern to J++ and C++ developers, who have the ability to create threads directly. Developers creating objects in Visual Basic do not need to worry about this, as there is no way for them to explicitly create a thread.

A thread is simply defined as a single path of code that is being executed. There are four threading models that a component could have. The threading model for a component is determined at the compile time for the component. There is a registry attribute for each component in MTS called ThreadingModel, which indicates what threading model MTS should use for this component. The four threading models are single threaded, apartment-threaded, free-threaded, and both.

Single Threaded

If a component is marked as Single Threaded, then all methods of that component will execute on the main thread. There is one main thread for each MTS application. Since there is only one thread, it means that only one method can execute at any given time. If there are multiple single threaded components that are being accessed by multiple clients simultaneously, then it is easy to see why a bottleneck will occur. Since only one method can execute at a time, all of the other methods will be sitting around waiting their turn. This can essentially grind a system to a halt.

A good rule of thumb to remember is Single Threading=BAD!

Apartment Threaded

In a component that is marked as Apartment Threaded, each methods of that component will execute on a thread that is associated with that component. Since each component running inside MTS has its own thread, this separates the methods into their own "Apartments", with each instance of a component corresponding to one apartment. While there is only one thread inside of a component, each instance of that component will have its own thread apartment. This will alleviate a great number of the problems that a single threaded component has. Since multiple components can be executing methods in their own apartments simultaneously, the scalability constraints that the single threaded components have are greatly relaxed.

Free Threaded

A Free Threaded object is also known as a multi-threaded apartment object. An application in MTS can have only one multi-threaded apartment (MTA) in it. This MTA can have zero or more threads within it. Any objects that are marked as free threaded will be created in the MTA, regardless of where they were created. Now, all of this may sound great. "Wow, multiple threads! Must mean great scalability!" This is not necessarily the case. To see the problem, we need to look at how calls are made from cone component to another.

When a call is made from one component to another component within the same the apartment, the call is a direct function call. In the Win32 environment, this is a very fast operation. If a call has to be made from one apartment to another, then a proxy needs to be created in order to make the call. What this does is add overhead to every function call, and slows down the system. Since a free threaded component will ALWAYS be created in the multi-threaded apartment, even if it was created from a single thread apartment, then all calls to access that component will have to be made by a proxy. And with proxy calls being slower than direct calls, the performance of this object will be reduced. This means that even though free-threaded components sound good, they will extract a performance penalty.


There is another type of threading model called Both. This is a special type of threading model in that the object has the characteristics of an apartment-threaded object as well as a free-threaded object. The advantage that this threading model brings is that no matter where the component is created, it will always be created within the same apartment as the object that created it. If it is created by a component running in a single-thread apartment, then it will act like an apartment-threaded component, and be created in the apartment. This means that the calls between the components can be direct and not require a slower proxy.

Likewise, if the new component is created by a component running in the multi-threaded apartment, it will act like a free-threaded component and be created in the MTA. This will allow the components direct access to each other, since they are running in the same apartment. In either case, to access this new component, proxy calls are not necessary. The access can be made using fast and efficient direct function calls...

Table of Contents

A New Generation of Web Solutions
ASP Fundamentals
The Active Server Pages Browser Objects
The Active Server Pages Server Objects
Scripting and Scripting Objects
Active Server Components
The Database Access Component
Advanced Database Techniques
Managing Enterprise Data
Getting into Client/Server
Creating Online Communities
Interacting with Internet Explorer 4
Introducing Transactions
Implementing ASP Security
An Electronic Commerce Case Study
Creating Components in the Electronic Commerce Case Study
Message Queuing in the Electronic Commerce Case Study
ASP and Internet Mail
Integrating Index Server
Case Study on Designing for Maximum Compatibility
Case Study in Legacy Component Reuse
VBScript Reference
JScript Reference
Active Server Pages Object Model
Scripting Objects and Server Components Methods and Properties
Active Database Component Reference
Remote Scripting Reference
Creating a System DSN
Configuring IIS
Server Variables
Server Errors
Useful Information
SSupport and Errat

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews

Professional Active Server Pages 2.0 5 out of 5 based on 0 ratings. 3 reviews.
Guest More than 1 year ago
This is probably one of the very best book for learning asp.certainly not for beginner's.Coverage of intrinsic asp objects,ADO technology,security(by richard harrison),component building using vb,MTS,index server for searching,reusing legacy components are treated at their best. even though the chapters are wordy the authors have done their best to treat the subject in a logical manner. it is definitely worth the money you pay for.
Guest More than 1 year ago
If you want to see and example of 'Too Wordy', Just check out the review above! I Think its OK as it is, certainly not as 'Wordy' as the two star reviewer above
Guest More than 1 year ago
One of the greatest book regarding ASP and dynamic pages.