Declarative Transaction Configuration

[turqoise]

Hi, I can't seem to get declarative transactions working for my setup.

I'm working on an ASP.NET 2.0 application with MSSQL2005 for the db.

The following is the configuration for my adotemplate, transaction manager etc

  <!-- Production Data Access Objects -->
  <db:provider id="dbProvider"
                 provider="SqlServer-1.1"
                 connectionString="Server=${db.server};Integrated Security=no;User ID=${db.user};PWD=${db.password};initial catalog=${db.schema};"/>

  <object id="adoTemplate" type="Spring.Data.Core.AdoTemplate, Spring.Data">
    <property name="DbProvider" ref="dbProvider"/>
  </object>

  <!-- Transaction Manager if using a single database -->
  <object id="transactionManager"
          type="Spring.Data.Core.AdoPlatformTransactionManager, Spring.Data">
    <property name="DbProvider" ref="dbProvider"/>
  </object>

  <tx:attribute-driven transaction-manager="transactionManager"/>

When I have not declared transaction attributes in my biz class, the application works fine. However once I have declared a method in biz class to be transactional, the daos all end up NULL.

The following code segment is how i declared a method to be transactional. Once [Transaction()] is in, my _codeTableDao ends up NULL.

        [Transaction()]
        public int InsertCodeTable(CodeTableInfo codeTableInfo)
        {
            _codeTableDao.UpdateCodeTableSequence(codeTableInfo.CodeTableTypeCode, codeTableInfo.ParentID, codeTableInfo.Sequence - 1);

            int codeTableID = _codeTableDao.InsertCodeTable(codeTableInfo);

Any ideas? What could I be missing?

[logicalmind]

Try this:

<object id="AdoTemplate" type="Spring.Data.Generic.AdoTemplate, Spring.Data">
    <property name="DbProvider" ref="DbProvider"/>
    <property name="DataReaderWrapperType" value="Spring.Data.Support.NullMappingDataReader, Spring.Data"/>
</object>

[turqoise]

Does that mean that I'll have to convert my whole application to using Generics before I can use declarative transactions in .NET 2.0?

[turqoise]

I've managed to figure out the issue.

I did not create interfaces for my Business classes. Didn't think that this would be a problem as I remember that for Java, I don't need my biz classes to have interfaces.

[Erich Eichinger]

Hi,

this turns out as the most often reason for AOP not working. Unfortunately in .NET methods are not virtual by default and thus cannot be overridden unless they are marked virtual or are part of an interface.

-Erich

[swalters]

Good timing on this post. I ran into this today and I should know better, but it still bit me.

Erich, is there anyway for Spring to raise an error when it tries to proxy an object that doesn't have an interface? I'm assuming it's not easy or it would have been done already . NHibernate will not allow the mapping of an object if the public properties are not marked virtual. Is there something similar that could be done with Spring?

-Shane

[Erich Eichinger]

Hi,

it isn't possible to make this the default behaviour. But I'm thinking about introducing some "strict" mode to make ProxyFactoryObject throw an exception in the case, that an object doesn't implement an interface.

Are there any other ideas/suggestions out there?

-Erich

[dlotts]

I think the default behavior should be to log an informational message when the proxy is created and the class (or generated proxy) does not implement an interface other than the standard interfaces:
Spring.Aop.Framework.IAdvised, Spring.Aop.Framework.IAopProxy, and System.Runtime.Serialization.ISerializable

If these are the only three interfaces implemented, its not likely that the proxy will be useful in most cases.

In my case (See the thread) a simple message would have helped me identify the problem immediately. I think the message is all that is necessary for most users. (assuming logging is correctly configured)

The strict setting could cause spring to throw an exception rather than log the message.

[swalters]

+1 on DLotts suggestion, except please log it as a WARN on the default so it will stand out better.

-shane

[steinard]

I agree, sounds sensible.


Cheers,
Steinar.