In the case from this article, you're controlling the connection, ensuring only one connection is made, so yes, I think that can work if you're making ADO.NET
calls directly. If you're using IBatis DataMapper, when you open a connection with something like ISqlMapSession session = sqlMap.OpenConnection(), the session is tied to a certain instance of ISqlMapper, which in turn, is tied to a particular SqlMapConfig. If you want to query with a different SqlMapConfig, you're going to need to use a different instance of ISqlMapper which isn't going to be able to participate in a session created by the first ISqlMapper instance.
Here's some code to illustrate:
using(TransactionScope scope = new TransactionScope())
using(ISqlMapSession session = sqlMap1.OpenConnection())
// The second ISqlMapper isn't participating in the session / connection created by sqlMap1.
Since sqlMap2 here isn't participating in the same session, sqlMap2 is going to open a new database connection to execute "someOtherStatement" so if both statements are executed within a TransactionScope on SQL Server 2005 with .NET 2.0, this will promote the transaction. I wish it would work in older versions of .NET. The TransactionScope should be smart enough to realize it's able to get a connection from the same connection pool and shouldn't promote it, but it didn't get this smart until .NET 3.5 and the ADO.NET
driver for SQL Server 2008, unfortunately.
Hope that's helpful,
On Sun, Apr 4, 2010 at 10:04 PM, Serge Boulay <email@example.com>
I suspect this would also work with .net 2.0 and sql server 2005.