ASP.NET Web Parts Overview
ASP.NET Web Parts is an integrated set of controls for creating Web sites that enable end users to modify the content, appearance, and behavior of Web pages directly from a browser. The modifications can be applied to all users on the site or to individual users. When users modify pages and controls, the settings can be saved to retain a user’s personal preferences across future browser sessions, a feature called personalization. These Web Parts capabilities mean that developers can empower end users to personalize a Web application dynamically, without developer or administrator intervention.
Using the Web Parts control set, you as a developer can enable end users to:
· Personalize page content. Users can add new Web Parts controls to a page, remove them, hide them, or minimize them like ordinary windows.
· Personalize page layout. Users can drag a Web Parts control to a different zone on a page, or change its appearance, properties, and behavior.
· Export and import controls. Users can import or export Web Parts control settings for use in other pages or sites, retaining the properties, appearance, and even the data in the controls. This reduces data entry and configuration demands on end users.
· Create connections. Users can establish connections between controls so that, for example, a chart control could display a graph for the data in a stock ticker control. Users could personalize not only the connection itself, but the appearance and details of how the chart control displays the data.
· Manage and personalize site-level settings. Authorized users can configure site-level settings, determine who can access a site or page, set role-based access to controls, and so on. For example, a user in an administrative role could set a Web Parts control to be shared by all users, and prevent users who are not administrators from personalizing the shared control.
Web Parts Essentials
The Web Parts control set consists of three main building blocks: personalization, user interface (UI) structural components, and actual Web Parts UI controls. For more details, see Web Parts Control Set Overview. Much of your development effort will focus on Web Parts controls, which are simply ASP.NET controls that can use the features of the Web Parts control set.
As an example of how Web Parts controls can be used to build personalizable Web pages, examine the following screen shot.
This page contains several basic elements of a Web Parts application:
· Use of zones for page layout. There are two columns that can contain controls: one has the Weather and Stock Quotes controls, the other has Hotmail and News controls. These columns in Web Parts terminology are called zones–regions on a page that contain Web Parts controls. Zones exist to lay out Web Parts controls on a page, and to provide a common UI for the controls. There can be one or many zones on a page, each zone can contain one or many Web Parts controls, and each zone can have a vertical or horizontal orientation for page layout.
· Web Parts controls within the zones. Each control has UI verbs (actions that a user can perform) that can appear as links, buttons, or clickable images on the control. In the preceding screen shot, notice that each control has a button in its title bar that exposes a drop-down menu. In the menus for each control are options to change details particular to that control, and other options to carry out common actions such as moving or deleting a control, and getting help. Some controls, such as the Weather control, allow users to personalize them so the controls display only information relevant to the user.
· Links to enable extensive personalization. These allow users to change the content, color, and layout of the page. For instance, if users click the Add Column link, a Web Parts application could enable them to add another column to a page. Or users could click the Add Content link, which displays a catalog of controls that that they can optionally add to the page. One of those could be a stock charting control. A user could add that control to one of the zones on the page, and could then connect it to the existing Stock Quotes control to chart the stock data it contains.
Developer Scenarios for Using Web Parts
You will typically work with Web Parts in one of three ways: creating pages that use Web Parts controls, creating individual Web Parts controls, or creating complete, personalizable Web applications, such as a portal.
Page developers can use visual design tools such as Microsoft Visual Studio 2005 to create pages that use Web Parts. One advantage in using a tool such as Visual Studio is that the Web Parts control set provides features for drag-and-drop creation and configuration of Web Parts controls in a visual designer. For example, you can use the designer to drag a Web Parts zone, or a Web Parts editor control, onto the design surface, and then configure the control right in the designer using the UI provided by the Web Parts control set. This can speed development of Web Parts applications and reduce the amount of code you have to write.
You can use any existing ASP.NET control as a Web Parts control, including standard Web server controls, custom server controls, and user controls. For maximum programmatic control of your environment, you can also create custom Web Parts controls that derive from the WebPart class. For individual Web Parts control development, you will typically either create a user control and use it as a Web Parts control, or develop a custom Web Parts control.
As an example of developing a custom Web Parts control, you could create a control to provide any of the features provided by other ASP.NET server controls that might be useful to package as a personalizable Web Parts control: calendars, lists, financial information, news, calculators, rich text controls for updating content, editable grids that connect to databases, charts that dynamically update their displays, or weather and travel information. If you provide a visual designer with your control, then any page developer using Visual Studio can simply drag your control into a Web Parts zone and configure it at design time without having to write additional code.
Web Application Development
Developing fully integrated and personalizable Web applications–such as a portal– involves the most comprehensive use of Web Parts. You can develop a Web site that allows extensive user personalization of the UI and content–with features similar to MSN. Or you can even develop a packaged application that can be shipped and used by companies or fee-based ISPs that provide portal hosting services.
In a Web application scenario, you could offer a complete solution for end users to manage and personalize the application. This could include a set of Web Parts controls that provide the desired features for the site, a consistent set of themes and styles that allow end users to personalize the UI in a consistent way, catalogs of Web Parts controls from which users can select the ones they want to appear on a page, authentication services, and role-based management (for example, allowing administrative users to personalize Web Parts controls and site settings for all users).
For each part of your application, you can extend the Web Parts control set as needed to provide greater control over the environment. For example, besides authoring custom Web Parts controls for the primary UI of your pages, you might also want to develop a custom Web Parts catalog that is consistent with the look and feel of your application, and gives users more flexibility to choose how controls are added to a page. Or you could extend a zone control to provide additional UI options for the Web Parts controls it contains. You could also write a custom personalization provider to give more flexibility and control over how the personalization data is stored and managed.
Connection Pooling in .NET Applications
Connecting to a database is the single slowest operation performed by a data-centric application. This document describes how reusing pooled connections, instead of creating new connections, can improve .NET application performance.
You can control connection pooling behavior by using the connection string options set for your ADO.NET data provider. For example, connection string options can define the following settings for the DataDirect Connect® for ADO.NET data providers:
• Number of connection pools (Max Number of Pools)
• Maximum connection pool size (Max Pool Size)
• Minimum number of connections in a connection pool (Min Pool Size)
• Number of seconds to keep connections in a connection pool (Connection Lifetime)
• Whether to enable Windows Integration authentication for the SQL Server data provider (Integrated Security)
This document also describes the performance advantages of DataDirect’s technique of handling dead connections in a connection pool, as well as tips on opening and closing connections. In addition, C# code examples illustrate how to create connection pools and how to handle distributed transactions when using a connection pool.
Creating a Connection Pool
Each connection pool is associated with a specific connection string. By default, the connection pool is created when the first connection with a unique connection string connects to the database. The pool is populated with connections up to the minimum pool size. Additional connections can be added until the pool reaches the maximum pool size.
The pool remains active as long as any connections remain open, either in the pool or used by an application with a reference to a Connection object that has an open connection.
If a new connection is opened and the connection string does not exactly match an existing pool, a new pool must be created. By using the same connection string, you can enhance the performance and scalability of your application.
In the following C# code fragment, three new DbConnection objects are created, but only two connection pools are required to manage them. Note that the connection strings for conn1 and conn2 differ by the values assigned for User ID, Password, and Min Pool Size connection string options.
DbProviderFactory Factory =
DbConnection Conn1 = Factory.CreateConnection();
“Host=Accounting;Port=1521;User ID=scott;Password=tiger; ” +
“Service Name=ORCL;Min Pool Size=50”;
// Pool A is created and filled with connections to the
// minimum pool size
DbConnection Conn2 = Factory.CreateConnection();
“Host=Accounting;Port=1521;User ID=Jack;Password=quake; ” +
“Service Name=ORCL;Min Pool Size=100”;
// Pool B is created because the connections strings differ
DbConnection Conn3 = Factory.CreateConnection();
“Host=Accounting;Port=1521;User ID=scott;Password=tiger; ” +
“Service Name=ORCL;Min Pool Size=50”;
// Conn3 is assigned an existing connection that was created in
// Pool A when the pool was created for Conn1
Once created, connection pools are not destroyed until the active process ends or the connection lifetime is exceeded. Maintenance of inactive or empty pools involves minimal system overhead.
Adding Connections to a Pool
A connection pool is created in the process of creating each unique connection string that an application uses. When a pool is created, it is populated with enough connections to satisfy the minimum pool size requirement, which is set by the Min Pool Size connection string option. If an application is using more connections than Min Pool Size, the data provider allocates additional connections to the pool up to the value of the Max Pool Size connection string option, which sets the maximum number of connections in the pool.
When a DbConnection object is requested by the application calling the DbConnection.Open() method, the connection is obtained from the pool, if a usable connection is available. A usable connection is defined as a connection not currently in use by another valid DbConnection object that has a matching distributed transaction context (if applicable).
If the maximum pool size has been reached and no usable connection is available, the request is queued in the data provider. The data provider waits for the value of the Connection Timeout connection string option for a usable connection to return to the application. If this time period expires and no connection becomes available, the data provider returns an error to the application.
IMPORTANT: Closing the connection using the Close() method of the DbConnection object adds or returns the connection to the pool.
Removing Connections from a Pool
A connection is removed from a connection pool and the connection to the database server is terminated when it remains idle (unused) for too long, or when a new connection that has a matching connection string is initiated by the application (DbConnection.Open() is called). The length of time that a connection can remain idle in a connection pool before being removed is determined by the Load Balance Timeout connection string option.
Before returning a connection from the connection pool to an application, the Pool Manager checks to see if the connection has been closed at the server. If the connection is no longer valid, the Pool Manager discards it and returns another connection from the pool, if one is available and valid.
The Clear Pool and Clear All Pools methods of the Connection object, introduced in the .NET Framework 2.0, clear connection pools. ClearPool clears the connection pool associated with a specific connection. In contrast, ClearAllPools clears all of the connection pools used by the data provider. Connections that are in use when the method is called are discarded when they are closed.
Note, however, that the data provider always retains the number of connections specified by the Min Pool Size connection option in a connection pool. So, setting the Min Pool Size connection option greater than 0 means that many connections in a pool effectively will ignore the Load Balance Timeout connection option.
Handling Dead Connections in a Pool
So, what happens when an idle connection loses its physical connection to the database? For example, suppose the database server is rebooted or the network experiences a temporary interruption. When the application attempts to connect using an existing DbConnection object from a pool, it could receive errors because the physical connection to the database has been lost.
DataDirect ADO.NET data providers handle this situation transparently to the user. The application does not receive any errors on the DbConnection.Open() attempt because the data provider simply returns a connection from a connection pool. The first time the DbConnection object is used to execute a SQL statement (for example, through one of the DataReader execution methods or the DataAdapter.Fill method), the data provider detects that the physical connection to the server has been lost and attempts to reconnect to the server before executing the SQL statement. If the data provider can reconnect to the server, the result of the SQL execution is returned to the application; no errors are returned to the application. The data provider uses the connection failover options, if enabled, when attempting this seamless reconnection. For more information about how DataDirect ADO.NET data providers implement connection failover, refer to ” Failover Support in DataDirect Connect for ADO.NET Data Providers.”
NOTE: Because the data providers can attempt to reconnect to the database server when executing SQL statements, connection errors can be returned to the application on a statement execution. If the data providers cannot reconnect to the server (for example, the server is still down), the execution method throws an error indicating that the reconnect attempt failed, along with specifics about the reason the connection failed.
DataDirect’s method of handling dead connections in connection pools allows for the maximum performance of the connection pooling mechanism. In contrast, some data providers periodically ping the server with a dummy SQL statement while the connections remain idle. Others ping the server when the application requests the use of the connection from the connection pool. Both of these approaches add roundtrips to the database server and ultimately slow down the normal operation of the application.
Handling Distributed Transactions
The Pool Manager groups the connections according to the requirement for transactions. If the requesting thread requires a specific transaction context, it must be matched to a connection with the same transaction context, for example, a connection that has been enlisted in distributed transactions.
Because closed connections are returned to the appropriate connection pool, you can close a connection even though a distributed transaction is pending. This means that you can still commit or rollback the distributed transaction until the connection is closed at the server.
Tips on Opening and Closing Connections
Open connections just before they are needed. Opening them earlier than necessary decreases the number of connections available to other users and can increase the demand for resources.
To keep resources available, explicitly close the connection as soon as it is no longer needed. If you wait for the garbage collector to implicitly clean up connections that go out of scope, the connections are not returned to the connection pool immediately, tieing up resources that are not actually being used.
Close connections inside a finally block. Code in the finally block always runs, regardless of whether an exception occurs. This guarantees explicit closing of connections. For example:
// Do some other interesting work
catch (Exception ex)
// Handle exceptions
// Close the connection
if (Conn1 != null)
If you are using connection pooling, opening and closing connections is not an expensive operation. Using the Close() method of the data provider’s Connection object adds or returns the connection to the connection pool. Remember, however, that closing a connection automatically closes all DataReader objects associated with the connection.
Tracking Connection Pool Performance
All DataDirect Connect for ADO.NET data providers install a set of Performance Monitor (PerfMon) counters that return information that lets you tune your applications for performance.
The following table describes the PerfMon counters that you can use to tune pooling for your application.
PerfMon Counter & Counter Description
1. Current # of Connection Pools: Returns the current number of pools associated with the process.
2. Current # of Pooled Connections: Returns the current number of connections in all pools associated with the process.
3. Current # of Pooled and Non-Pooled Connections: Returns the current number of pooled and non-pooled connections.
4. Peak # of Pooled Connections: Returns the highest number of connections in all connection pools since the process started.
5. Total # of Failed Connects: Returns the total number of attempts to open a connection that failed for any reason since the process started.
Refer to the Microsoft .NET Framework documentation for information about using PerfMon counters.