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())
// 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.