All DataDirect Connect for ADO.NET data providers support both local and distributed transactions.
All DataDirect Connect for ADO.NET data providers use 100% managed code in supporting local transactions. Local transactions are implemented within the .NET Framework. A local transaction uses the internal transaction manager of the underlying database.
If your application connects to only one database and you have no requirement to connect to another database, use local transactions, as shown in
Figure 2-2. Local transactions are always faster than distributed transactions, which require additional logging and network round trips. In addition, local transactions provide the added benefit of increased security because the data provider does not need to call unmanaged code.
The DataDirect Connect for ADO.NET data providers support distributed transactions only when the application is written to serviced components. For a general discussion of using serviced components, refer to the Microsoft ADO.NET Framework SDK documentation.
The DataDirect Connect for ADO.NET data providers support distributed transactions using the Microsoft Distributed Transaction Coordinator (MS DTC), which is provided through System.Transactions. You must include specific code, such as System.Transaction, in the namespace of your application.
Figure 2-3 illustrates using a distributed transaction.
Because the DataDirect Connect for ADO.NET data providers are managed data providers, you can still enjoy some of the benefits of the .NET Framework security when you use distributed transactions. The security afforded by the data provider, with the security defined in the database, provides good protection when you use distributed transactions.
See “Handling Dead Connections in a Pool” for information about how connections used in a distributed transaction are processed in a connection pool.