Multiple Active Result Sets (MARS) and object graph in Csla

[Chicagoan2016]

Hi,
We have a Csla 4.1.x application with SQL server as backend (stored procs and ADO.NET code).
I noticed that to use an object graph of Csla objects containing Parent, children and grand children object, we have to enable
Multiple Active Result Sets in the connection string.
I also read that MARS is not thread safe (docs.microsoft.com).
Is this something we should be concerned especially if we want to use async in the future (in the same project)?
Kind Regards

[TheCakeMonster]

I think it might depend on exactly what order you have your code as to whether you need MARS enabled. In the past I wrote my data access code in the data access methods themselves. In that scenario, you are looping through the resultset from the stored procedure and loading it into the CSLA collections as a single pass. That could well result in child operations whilst the parent operation is still ongoing, and thus result in MARS being important.

When I wrote DesiGen, I switched to a repository-style approach, where my repository loads all of the data from the data source into a list of DTOs, and then returns that list to the CSLA object, which then initiates a second iteration over that list. In this second scenario, the resultset of a parent is closed prior to initiating any data access on a child. In this scenario I don't have MARS enabled, because I don't need it. Repository = DAL, more or less exactly, if that's your preferred teminology.

I think you can avoid the need for MARS as long as you have an intermediary set of DTOs into which you load data, prior to loading any CSLA objects.

I don't know for sure - I haven't looked - but I suspect that MARS is not thread-safe in the sense that it shouldn't be accessed from multiple threads concurrently. Using async/await doesn't cause concurrent execution from multiple threads. Multiple threads may well be in use, but not in parallel - as long as you remember the await. The await causes each operation to happen one after another, and this massively reduces the potential for thread-synchronisation issues.

I've never enabled MARS on any of my systems, despite using very complex object graphs. In the past I did have MS-DTC enabled which allowed multiple, separate connections to be opened. However, MS-DTC/distributed transactions do not work on .NET Core/5/6, so that's no longer the case. DesiGen has hit no problems, as a result of the double iteration.

As an aside, DesiGen is what makes the difference in terms of cost versus benefit here. I didn't used to use the Repository pattern because there was a development overhead to creating DTOs, repository interfaces and repository implementations. It was more code to write, somehow. Ouch. However, with a code generator that supports generating multiple artefacts per data structure definition, there is no manual overhead to worry about. A one-to-many code generation system is one of the things that makes DesiGen just a bit different from what I used before (for reference: I was a long time CodeSmith user)

[Chicagoan2016]

Thank you @TheCakeMonster ,
We have DTOs and we use Encapsulated invoke in our business objects. This project has been years old but we have followed the ProjectTracker sample in Csla.
Our Fetch code looks like this,

   private void DataPortal_Fetch(ExampleCriteria crit )
        {
            using (var dalManager = DataAccess.DalFactory.GetManager())
            {
                var dal = dalManager.GetProvider<DataAccess.ISampleDal>();
                var data = dal.FetchSamplebyID(crit.SampleID);
                using (BypassPropertyChecks)
                {
                    SampleID = data.SampleID;
					..
					..
					..
					..
                   
                }
            }
            SampleChildren = DataPortal.FetchChild<SampleChildren>(this);
        }

What changes should we implement?
Regards

[TheCakeMonster]

@Chicagoan2016 I can't see a problem in that bit. I'd say the problem is more likely to be in the way you handle the child collection - SampleChildren - especially if each SampleChildren has children as well. Look for a place where you are iterating a collection, and within that loop, you iterate another one - a child of each of the items in the outer iteration.

[rockfordlhotka]

ADO.NET has never been threadsafe. Microsoft has kept ADO.NET up to date as they've added async/await to the .NET framework and .NET Core, so I don't think this is a real worry.

Basically, if you aren't manually creating threads using Task.Run or something like that, and you aren't somehow defeating all the protections against sharing a single database connection across multiple server calls, it should work fine.

In CSLA 6 this means injecting the database connection into your DAL as a scoped service, which is normal. ASP.NET and CSLA work to ensure each server request has its own scope, and therefore has its own database connection.