Managing transactions in multi-tiered applications

When client applications apply updates to the application server, the provider component automatically wraps the process of applying updates and resolving errors in a transaction. This transaction is committed if the number of problem records does not exceed the MaxErrors value specified as an argument to the ApplyUpdates method. Otherwise, it is rolled back.
In addition, you can add transaction support to your server application by adding a database component or using passthrough SQL. This works the same way that you would manage transactions in a two-tiered application.

If you have a transactional data module, you can broaden your transaction support by using MTS or COM+ transactions. These transactions can include any of the business logic on your application server, not just the database access. In addition, because they support two-phase commits, they can span multiple databases.
Only the BDE- and ADO-based data access components support two-phase commit. Do not use InterbaseExpress components if you want to have transactions that span multiple databases.
Important Note:
When using the BDE, two-phase commit is fully implemented only on Oracle7 and MS-SQL databases. If your transaction involves multiple databases, and some of them are remote servers other than Oracle7 or MS-SQL, your transaction runs a small risk of only partially succeeding. Within any one database, however, you will always have transaction support.

By default, all IAppServer calls on a transactional data module are transactional. You need only set the transaction attribute of your data module to indicate that it must participate in transactions. In addition, you can extend the application server’s interface to include method calls that encapsulate transactions that you define.

If your transaction attribute indicates that the application server requires a transaction, then every time a client calls a method on its interface, it is automatically wrapped in a transaction. All client calls to your application server are then enlisted in that transaction until you indicate that the transaction is complete. These calls either succeed as a whole or are rolled back.

Note:Do not combine MTS or COM+ transactions with explicit transactions created by a database or ADO connection component or using passthrough SQL. When your transactional data module is enlisted in a transaction, it automatically enlists all of your database calls in the transaction as well.

Comments

Popular posts from this blog

TClientDataSet::AppendData and TClientDataSet::BeforeGetRecords

OleVariant

TClientDataSet::GetNextPacket