2009-11-23

Auto-transactions API

Which auto-transactions API I'd like to have in ideal ORM?

In a typical business application we have a set of session-bound classes, for example our business classes, services, etc... Each method, property or constructor in these classes can be either transactional or not transactional. We should decide which of them will be transactional and inform ORM about this, using a set of attribute-based rules. I'd like these attributes to allow me to specify following rules:
  • All members of this class are not transactional by default
  • All public methods of this class and all its inheritors are transactional by default
  • This method requires new nested transaction even if some transaction is already open
  • This member doesn't require transaction
  • This method requires transaction with "ReadCommited" isolation level
Moreover I'd like API to be very simple and intuitive. It should allow to define default behavior and manage transactional behavior in flexible way.

When I starting to implement my model and business logic layer, I decide which policy to use. I can make all public members in all classes of my model transactional by marking base class as "Transactional", and then mark some members as not transactional by appropriate attribute. On other hand I can make everything not transactional, except public methods in some service classes, and open transactions manually each time I need them. I can use third approach, for example make methods transactional, but properties not. It depends on my solution architecture, and it's impossible to find universal right way.

So I think we need something like this:

[Transactional] attribute that can be applied to a session-bound class or its member. Attribute should have following options:
  • Should this attribute be applied to inheritors or not
  • Which members it should be applied to (methods, properties, constructors)
  • Visibility of members this attribute should be applied to (public, internal, protected)
  • Are members this attribute applied to transactional or not. Another alternative is to mark not transactional members by special [NotTransactional] attribute
  • Required isolation level for transaction
  • Whether new transaction is required or any existing one is enough.
There is a small example that illustrates how I'd like it to work. In this example I've made all entities not transactional and all public methods of DocumentService - transactional by default.

  1. [NotTransactional(InheritBehavior = true)]
  2. public class MyEntityBase : Entity
  3. {
  4. }
  5.  
  6. public class Document : Entity
  7. {
  8.   [Transactional]
  9.   public void BusinessMethod()
  10.   {      
  11.   }
  12.  
  13.   [Transactional(Options = TransactionOptions.New,
  14.     IsolationLevel = IsolationLevel.Serializable)]
  15.   public void AnotherBusinessMethod()
  16.   {      
  17.   }
  18. }
  19.  
  20. [Transactional(
  21.   MembersType = MemberTypes.Method,
  22.   MembersVisibility = Visibility.Public)]
  23. public class DocumentService : SessionBound
  24. {
  25.   public Document FindLastDocument()
  26.   {
  27.   }
  28.  
  29.   public void RemoveAllDocuments()
  30.   {
  31.   }
  32.  
  33.   [NotTransactional]
  34.   public override string ToString()
  35.   {
  36.   }
  37. }

As you can see MyEntityBase class marked by [NotTransactional] attribute, but if we assume that all classes are not transactional by default we must not mark it by this attribute.

    2 comments:

    Alex Yakunin said...

    AFAIK the content here is obsolete:
    - There is no [NotTransactional(InheritBehavior = true)]
    - [ActivateSession] and [Transactional] replicate the behavior you describe.
    - [Infrastructure] or [SuppressActivation] applied on class \method level partially simulates class-level behavior.

    Alex Kofman said...

    > AFAIK the content here is obsolete

    Yes, if you mean auto-transactions implementation in DataObjects.Net.

    Note, that in this post I described auto-transactions API I'd like to have in abstract ideal ORM.