Houston we have a problem. I've been using both CSLA 4.x and 3.8 for some time now, and haven't run across this issue until now, where we are upgrading a CSLA 3.8 based project to CSLA 4.5.
This specific project executes along with other external application components from COM+ (Enterprise Services), making it sensitive to 2PC and Transaction Isolation levels.
Context: I'm referring to using the [Transactional( TransactionalTypes.TransactionScope )] attribute on the DataPortal_XYZ methods.
For most CSLA projects, the transaction
starts from the DataPortal_XYZ methods and seldom goes further to include other
transactions. We have combinations of both, and specifically, we let the
DataPortal_XYZ methods "take-on" the transaction isolation level of the caller.
This may vary in that one caller has one isolation level, and another caller
may use a different one (don't you just love integration work 
).
What cannot be done is to have a caller use one isolation level, and then have the subsequent DataPortal_XYZ method execute under a different isolation level, when it is enrolled in the same transaction scope of the caller (TransactionScope = Required).
The implementation of the CSLA 3.8 Transactional DataPortal code had created a new System.Transactions.TransactionScope instance using the default parameterless constructor. This default constructor assumes a Scope = Required but specficially does not specify an isolation level. There is no default here, it's unspecified.
Here is the code for the CSLA 3.8 version: http://www.lhotka.net/cslacvs/viewvc.cgi/core/branches/V3-8-x/cslacs/Csla/Server/TransactionalDataPortal.cs?revision=4288&view=markup
The implementation of the CSLA 4.5 Transactional DataPortal looks to have some refactorings and actually creates a new System.Transactions.TransactionScope instance using a constructor overload that takes both the Scope and the Isolation level as parameters. The Scope is defaulted to Required (when not expressly specified in the DataPortal_XYZ attribute), which matches the original behaviour. But, the isolation level is also specified in this overload, using a default value of Serializable and therein lies the rub, it's not unspecified/omitted.
Here is the code for the latest CSLA 4.5.x version: https://github.com/MarimerLLC/csla/blob/master/Source/Csla/Server/TransactionalDataPortal.cs
This default of Serializable is the safest (though most expensive) isolation level and makes a good default. Unfortunately, it is not the same behaviour as with CSLA 3.8, and does not allow the "flow from caller" scenario.
Please note I'm pointing out a
subtle difference here.
Of course you can specify any isolation level that you want in the
DataPortal_XYZ attribute (e.g. [Transactional(
TransactionalTypes.TransactionScope, TransactionIsolationLevel.RepeatableRead )] but
that is not the issue. The issue is that by specifying it in the first place, results
that it will always be that isolation level, regardless of the isolation level flowed from caller's scope (if one is present).
With CSLA 3.8's implementation it would also have IMPLICITLY defaulted to serializable, but only if the isolation level from a caller's scope was not different, in which case it would've taken the isolation level of the caller.
With CSLA 4.5's implementation it is EXPLICITLY set to serializable by CSLA's default behavior, resulting in a transaction exception faulting the mismatch of isolation levels (the one from the callers scope not matching the one set on the DataPortal_XYZ.
It turns out the System.Transactions.IsolationLevel
enumeration has an Unspecified option.
Refer: http://msdn.microsoft.com/en-au/library/system.transactions.isolationlevel.aspx
I've done some tests and if I manually create a transaction scope using the same overload as CSLA 4 but then use this "Unspecified" option is works as expected and behaves as per CSLA 3.8 allowing me to "flow" the isolation level from the caller.
Unfortunately, the ApplicationContext.DefaultTransactionIsolationLevel does not have an Unspecified enumeration either).
@Jonny / @Rocky - Would you accept this as an issue for rectification?
I really hope so, as this is a show stopper for our project development at the moment.
In mind, the fix would be to either:
-
Add a matching "Unspecified" option to the CSLA
TransactionIsolationLevel enumeration and use that is the default value instead
of Serializable in the method:
private IsolationLevel GetIsolationLevel(TransactionIsolationLevel transactionIsolationLevel) {...}
(Probably the easiest and least amount of code changes).
alternatively, - Find some way call the same default parameterless constructor as CSLA 3.8 when no express values are set for the Transactional attribute on the DataPortal_XYZ methods.
I'd be happy to try and put a pull-request together if that would help further.
Thanks a million,
Jaans