I think, in data stores that support this, the transactions are usually multiplexed (each transaction is separate and associated with different commands, same "connection"). I'm not sure which databases support this now, certainly "middle tier providers, JDBC type 3" (providers that are servers themself and can connect to multiple "underlying" databases, eg. DataDirect SequeLink-ADO or Openlink Virtuoso) could support non-distributed transactions, one-per underlying database.
True nested transactions (rather than nesting of transactions, which most RDBMS support rather than nested) are described in the Bernstein and Newcomer transaction book and Gray and Reuter's "Transaction Processing:Concepts and Techniques" book. Bob Beauchemin [EMAIL PROTECTED] -----Original Message----- From: Sean Greer (SBI-Chico) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 1:46 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] OleDbConnection Question Bob, Thanks for the response (Jim Arnold, as well). I hadn't considered multiple transactions per connection. Would the transaction be nested and would an inner need to be committed/rolled back prior to an outer? Are there any data stores that currently support multiple transactions? I'd like to do a little more reading on this. Anyway, now that I have a good reason (extensibility) I will happily pass the transaction. Thanks. Seang -----Original Message----- From: Beauchemin, Bob [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 11:29 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] OleDbConnection Question Having the transaction be associated with a Connection class rather than having a separate Transaction class enforces the semantic that each Connection can only have a single associated Transaction. Although this is the way most relational databases (including SQL Server) work today, that is not the way all data stores work (or might work in the future). OLE DB represented the transaction by an ITransaction pointer, ADO simplified this by having a single transaction associated with an ADO.Connection. In ADO.NET, Connection.BeginTransaction returns a Transaction instance which must be associated with every Command that partipates in the transaction. You call Transaction.Commit or Transaction.Rollback. This is much more flexible, extensible, and OLE DB-like. Hope this helps, Bob Beauchemin [EMAIL PROTECTED] -----Original Message----- From: Sean Greer (SBI-Chico) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 1:16 PM To: [EMAIL PROTECTED] Subject: [DOTNET] OleDbConnection Question Why did they not make the current transaction available through the OleDbConnection class? It is truly a pain in the a%# to be forced to pass the transaction to every object that is going to do a database operation when they could of made it available via a public property on the connection object (e.g., OleDbConnection.CurrentTransaction). Any comments on this? Seang You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
