Transaction support (Ado)

[erijvordt]

Hi,

I was wondering about the state of transaction support in the Spring.Ado.Transaction namespace, and related namespaces. Is this already usable, together with the AOP support, to declaratively apply transactions to methods? If so, are there any examples? I searched google but found exactly one example in Chinese (search for AdoPlatformTransactionManager to find it).

Same for the Ado support itself, I see the AdoTemplate (in the latest CVS source) and related classes, but no concrete implementations of that class, such as SqlTemplate or OleDbTemplate, though it seems easy to implement those myself.

For another project, and my current one, I already implemented my own OleDbTemplate and a lot of related stuff, which was inspired by Spring for Java, and I would like to extend that with the ability to use declarative (Ado) transactions.

I looked at the code of the transaction classes, as well as the example above, but what I don't understand is this: if the AdoPlatformTransactionManager is supposed to be a singleton (like the PlatformTransactionManagers in Spring Java), why does it contain instance members _connection and _transaction, which are set when a client (read IIS request/thread in our ASP.NET app) begins a transaction? This is not threadsafe, since there can be only one active connection/transaction. Or should it not be a singleton in the Spring application context? The Java trx managers don't have something like this either, they work with threadsafe DataSources and SessionFactories etc.

Thanks for any help. I really want the declarative transaction support, because without it we have to implement the Ado transactions manually all over the place.

Regards,
Edwin

[Aleks Seovic]

Hi Edwin,

Spring.AOP can certainly be used to apply transaction advice to your methods, but I'm not sure if advice itself, Transaction attribute and platform transaction manager are fully implemented and tested.

Griffin Caprio worked on transaction stuff, so I will doublecheck with him and let you know.

Regards,

Aleks

[Abadio]

Hi Edwin, in Framework 2,0 a new namespace exists (System.Transaction) that it easily makes possible to implement with AOP declarative transactions. I have used of this form:

public void Save(Pessoa infPessoa)
{
#region Sanity Check
if (infPessoa == null)
{
throw new ArgumentNullException("objPessoa");
}
#endregion

if (infPessoa.IsNew || infPessoa.Dirty)
{
DbCommand dbCommand = GetTemplateDatabase().GetStoredProcCommand(infPess oa.IsNew ? PessoaDAO.Proc_Insert : PessoaDAO.Proc_Update);
SetParametersCmdPessoa(infPessoa, dbCommand, infPessoa.IsNew);
GetTemplateDatabase().ExecuteNonQuery(dbCommand);

if (infPessoa.IsNew)
infPessoa.Codigo = Convert.ToInt32(GetTemplateDatabase().GetParameter Value(dbCommand, PessoaDAO.Prm_CodPessoa));
}
}

public class TransactionAroundAdvice : IMethodInterceptor
{
#region IMethodInterceptor Members
public object Invoke(IMethodInvocation invocation)
{
object returnValue;
using (TransactionScope transScope = new TransactionScope(TransactionScopeOption.Required))
{
returnValue = invocation.Proceed();
transScope.Complete();
}
return returnValue;
}
#endregion
}


<object id="cpessoaDAO" type="Spring.Aop.Framework.ProxyFactoryObject, Spring.Aop">
<property name="target">
<object id="cpessoaDAOObjectTarget" type="Coc.Academico.DAL.PessoaDAO, Coc.Academico.DAL" singleton="true"/>
</property>
<property name="interceptorNames">
<list>
<value>transactionAroundAdvice</value>
</list>
</property>
</object>

Regards,
Abadio

[Mark Pollack]

Hi Edwin,

The state in the sandbox for ADO.NET stuff is “under active development”. However, I did incorporate some minimal usage into a current project of mine without any issues so the basic operations of AdoTemplate/AdoCommand and declarative transaction management is working as well as the support for code based mappers from DataReaders to domain objects. What is not there, roughly speaking, is a fully fleshed out API for AdoTemplate, DataSet support, isolation level, savepoints, and exception translation into the DAO exception hierarchy.

I’m sure you are scratching your head here – the missing piece is that the Ado directory under Spring.Data, where you saw AdoPlatformTransactionManager, is older stuff that is not used in the current implementation. I was just keeping it around for the sake of posterity. To avoid confusion, I’ve removed it from CVS. The AdoPlatformTransactionManager you should be looking at is in Spring.Data/Data and doesn’t have the issues you mention.

There is some sample code located in sandbox\test\Spring\Spring.Data.Integration.Tests. These show usage of AdoTemplate and AdoCommand as well as the various ways you can apply declarative transactions. The best way imho is to use attributes on the methods of your DAO object, for example in TestObjectManager


&#91;Transaction&#40;&#41;&#93;
public void SaveTwoTestObjects&#40;TestObject to1, TestObject to2&#41;
&#123;
testObjectDao.Create&#40;to1.Name, to1.Age&#41;;
testObjectDao.Create&#40;to2.Name, to1.Age&#41;;
&#125;


Take a look at declaritiveServices.xml and DeclartiveTxTets.cs for the supporting configuration and code.

The AdoTemplate class, as in the Java case, is structured around the idea that you create a single instance of the template class and can share it among all your DAO objects. This means that you have to pass all command parameters in on a single method. This works ok for simple cases but can start to be a bit cumbersome when you pass in multiple parameters. AdoCommand lets you build up state, so you need an instance per DAO operation (say create/update or delete). Typically you would do all the creation and preparation work of an adoCommand in initialization code and just set the values of parameters and execute inside the DAO ‘worker’ method (create/update etc).

The key abstraction for the database is the ado.net 2.0 like IDbProvider interface. This is where I am trying to put all database specific dependencies. My goal is to evolve it into a driver like class such that I can keep the AdoTemplate/AdoCommand code provider independent. However, I’m pretty sure people will want some provider specific template/command functionality, not that you couldn’t do it with the ‘generic’ AdoTemplate/AdoCommand, but for the syntactical convenience. So far I’ve just been using SqlServer 2000. Other sundry cleanup is to remove the creation of a tx inside the AdoTemplate code if it doesn’t find one in the current thread since I now understand it goes against the design of the template classes. In the case of no tx manager/tx interceptor then an implicit transaction is created by ado.net if it isn’t specified on the IDbCommand.

Anyway, long story short, take a look in those directories, give it a whirl and let me know what you think. I’d love to have you on board as an early adopter! I gather you need support for the OleDb provider?

Cheers,
Mark

[Mark Pollack]

Hi Abadio,

That is a nice piece of AOP advice, in particular for the case of doing distributed transactions in ADO.NET 2.0. Migrating that code into a Ado2DtcPlatformTransactionManger would require manual enlisting instead of the using construct but the idea is the same. Thanks for the tip.

On a side note, I plan to provide a ADO.NET 1.1 platform transaction manager that uses ServiceConfig to support distributed tx in 1.1, as the API is pretty simple but the limitation being use only in Windows 2003 or XP SP2. The other, uglier, possiblity it to use our Serviced Component support and use standard EnterpriseServices for distributed transactions.

Cheers,
Mark