Page-Based Transaction Model

In web-based applications, it's particularly difficult to accumulate transaction information across multiple pages, moving from one page to another, because of the stateless nature of the web.  This makes it important to understand what constitutes a transaction and when it should be committed to the database.  For example, a typical web-based order check out process, such as a shopping cart, collects different aspects of the order in a series of pages, such as the customer’s name and address, credit card information, and shipping instructions.

The difficulty is that there are few options for storing information collected on those pages other than in the database, in the .NET cache, or in browser cookies.  Unfortunately, storing a user’s transaction information in browser cookies poses security and bandwidth issues.  So, for most applications, storing transaction information in the database is the best option.  This makes it important to understand what constitutes a transaction and when it is committed to the database.

Iron Speed Designer creates applications with a “page-based” transaction model.  This means that all of the changes made to any underlying database table on the current web page are submitted when the user clicks “OK” (or takes a similar action on the page).  I.e., upon clicking “OK” (or similar action), all changes made on the page are committed to the database as part of a single transaction.  Specifically, Iron Speed Designer applications use the transaction classes in ADO.NET to perform commits and rollbacks.

This order form illustrates how data can be called from multiple database tables into one page in a parent-child relationship.  When “Save” is clicked, records are inserted into several tables, including the Order, Order Details, and Customer tables.  In particular, multiple records are inserted into the Order Details table, one record for each line item.  The entire transaction is concluded with a single commit.

Iron Speed Designer uses stored procedures to update the database when appropriate.  If there are multiple related records being added or updated as part of a single transaction (e.g., Orders with multiple Order Items), then each record is updated individually requiring multiple round-trips to the database.  The record insertions, updates, and deletions themselves are performed within database stored procedures, but the application logic calling these stored procedures is resident in the application code.

In a multi-part transaction, the entire transaction is concluded with a single COMMIT statement at the end of the transaction.  I.e., while these many-to-many updates do require multiple trips to the database, they are committed to the database by a single COMMIT at the end of the transaction.

See Also

Transaction Management