How The Profile Page Works

"> B A C K

V I E W S O U R C E

Functional Overview

The user, having logged into the Frequent Flyer application, goes to the Member Profile page: Profile.asp. This page consists of a large form full of user information retrieved from the database when the page loads. The user makes changes to the page by editing the form and clicks on the submit button when finished. The form is validated using JavaScript. If the validation is successful, then the form is posted to the same page: Profile.asp. Since a form value was passed to the page to indicate that this is a submission request, the page does not display any of its HTML, but rather takes the form values and sends them to the components that handles updating the database. If no errors are returned, then Profile.asp redirects to Default.asp.

Data Model

Four tables from the Frequent Flyer database are involved: the diagram below is only a subset of the entire data model

Data Model of tables used to update profiles

Table	Comment
Member	Includes information about the user including contact information and preferences such as seating, smoking, and eating. One record from this table is involved in the scenario. When a new member joins, a SQL Server default value on the Mileage column gives the new member 50,000 miles.
Interests	A list of interests such as Fishing, Golfing, Tropical Vacations. All of the records from this table are retrieved in order to create the check boxes for each of these interests.
MembersInterests	Consists of records which list an InterestID and a MemberID. When querying the database all the records which match the current AccountID are retrieved. When updating the database, all of these records are deleted and as many new records are written as the user has indicated as interests on the form.
InterestCategories	Is queried along with Interests to provide a category name that will appear with the interests.

Components Used

The ExAir component is written in Microsoft Visual Basic 5 and is called from profile.asp. It includes a class called Member which handles all changes to the Members and MembersInterests tables of the database.

The methods involved in the process described above are:

Table	Comment
Member.GetForID	Retrieves account information about the user by querying the Member database with the AccountID (which was stored in a session variable when the user logged on).
Member.ListInterests	Retrieves all of the interests, along with the category name of the interests, and indicates whether this particular user has indicated each interest. All of this is achieved in one operation with a SQL SELECT statement that performs a LEFT JOIN along with a nested INNER JOIN.
Member.Update	Writes all of the changes to the Member table.
Member.UpdateInterests	Writes all of the changes to the MembersInterests table.

Transaction Usage

The Member class is registered with Microsoft Transaction Server (MTS). The four methods listed above all contain code that manages the transaction so that if connections to the database fail, or other errors occur while the components are running, the transaction can be safely aborted. This code also insures that as soon as the components are done performing their allotted tasks, they can be reused by other clients, thus providing maximum scalability.

Process Isolation

The member component is registered with Microsoft Transaction Server. It is located in the Exploration Air package. The package runs in a separate process from IIS, giving process isolation. Separating the business components into another process will help protect the IIS process from corruption or failure due to bad behavior of the business components. This protection should minimize the chances of the Web server being interrupted.

Transactions

The member component's transactional property is set to Required. By setting the transactional property of the component MTS will guarantee that the information that is either read or updated will always be protected from corruption. The following protection is guaranteed.

Atomic - Member profile and interests are updated as one atomic piece of work.

Consistent - Interests will always match the current member profile.

Isolated - When updates are being made others are locked out of that data.

Durable - Updates are committed and made durable in SQL Server.

In the case of a failure, whether programmatic or system, MTS will automatically abort the current transaction.

Resource Management

Many resources that are used in an application can be shared among all of the components in the application. Resources such as database connections are automatically being pooled. This allows for very quick access to data as the connection does not need to be "rebuilt" each time it is requested but rather can be shared among many users accessing the same data. Other resources, such as threads, are also shared.

State Management

The above services, such as database connections and threads, are provided automatically by registering the components with MTS. In order for MTS to optimize state management on the server the component "tells" MTS at the end of a method call that it has completed its work and no longer needs the state to be held. MTS is then able to release the state of the object as soon as the method is complete. Although clients may maintain references to objects the actual activations of components will exist only when methods are executing on the object. This behavior allows many more users to access the same server.