How to migrate transaction handling from CSLA 4.8 to 7.0

[ecaldentey]

Hello everyone,

I am migrating an application from Csla 4.8 to 7.0. My application uses Oracle as the database, and all operations are performed through stored procedures invoked from a DAL (Data Access Layer) project, without using Entity Framework.

In the Business Logic Layer, I handle transactions from the Root object using the TransactionManager and ApplicationContext classes.

The following code is a summarized example of how an Insert is performed from the business layer, invoking the DAL:

protected override void DataPortal_Insert()
{
using (var ctxConn = TransactionManager<OracleConnection, OracleTransaction>.GetManager(MyConnectString, false, MyConnId))
{
Csla.ApplicationContext.LocalContext[MyConnId] = "TransacOK";

    using (BypassPropertyChecks)
    {
        MyObjectDto.Id = this.Id;
        // ...

        result = dal.Insert(MyObjectDto);

        // ...

        FieldManager.UpdateChildren(this);

        if (Csla.ApplicationContext.LocalContext[MyConnId].ToString() == "TransacOK")
        {
            ctxConn.Commit();
        }

        ApplicationContext.LocalContext.Remove(MyConnId);
    }
}

}

On the DAL side, when the method is invoked, transaction handling is performed as follows:

// Creates a transaction if it doesn't exist (Root Object) or retrieves the existing open connection (Child Object)
ctxConn = TransactionManager<OracleConnection, OracleTransaction>.GetManager(MyConnectString, false, MyConnId);
OracleCommand cmd = new OracleCommand(procedureName, ctxConn.Connection);

cmd.CommandType = CommandType.StoredProcedure;

cmd.Parameters.Add("p_id", OracleDbType.Decimal).Value = myObjectDto.Id;
// ...

cmd.Transaction = ctxConn.Transaction;
cmd.ExecuteScalar();

In version 7, the TransactionManager class is deprecated, and the ApplicationContext class is no longer static. It must be instantiated. I haven't been able to find an example that demonstrates how to manage transactions. I am injecting it into the Insert method as follows, but I don't know how to share the connection between parent and child classes:

[Insert]
private void Insert(MyRootDto myRootDto, [Inject] IMyRootDal dal)
{
// Implementation
}

Can someone help me solve this, preferably with an example or point me to where I can find one?

Thank you in advance.

Esteban

[rockfordlhotka]

As a general rule, using dependency injection (DI), you either inject the database connection into your root-level operation method. Starting in CSLA 7 we've embraced DI to conform to the standard .NET way of doing things.

You can either inject a connection to the root, and start/end the transaction there (which is probably normal), or you can inject a transaction into every dataportal method, and commit/rollback that transaction in the root.

In your example, in your dataportal operation method(s) you are injecting the DAL, which is good.

In the DAL, you should inject the database connection so you can use it. In your root level DAL method you should start/end the transaction. Pseudocode:

  public class MyDal : IMyDal
  {
    public MyDal(DataConnection connection) {}

    public MyRootDto Insert(MyRootDto dto)
    {
      _connection.StartTransaction();
      // map DTO properties to entity properties here
      _connection.CommitTransaction();
    }
  }

The idea is that this would be no different from what you'd do any any non-CSLA code when building data access layers in modern .NET.

[ecaldentey]

Hello Rocky,

To perform the migration, I bought your book "Using CSLA Blazor and WebAssembly," and I have been following your guidance in the book, as well as examining the code in the "BlazorExample" sample project. I've been running the code to understand the logic. In that project, the code works well, whether I reference DataAccess.EF or DataAccess.Mock.

However, my intention is not to transition from version 4.8 of CSLA to 5.2, but to go directly to the latest version, 7.0. Therefore, when you mentioned in your previous response the following, which was also my original thought:

"The DAL and data layer types should be registered on the app server so they can be injected into your data portal operation methods."

But in the book, on page 116, you state the following:

"Now that the DAL exists, the client-side Blazor app needs to be configured to use those types. This is done in the Main method of the Program class.

You can see how the AddTransient method is used to tell dependency injection to return an instance of the PersonDal type any time the IPersonDal type is requested. Finally, in the business library, you will implement a PersonEdit domain type that makes use of the DAL."

I am a bit confused, and I am not sure if I am misunderstanding, but what I gather from that part is that if you register the interfaces in the DAL in the client project, and as it was not recognizing the interfaces when I registered them in the server project, I moved them to the client project, and with that, injection was working. However, it seems that I am not doing it correctly.

Another thing is that now in CSLA 7, the UseCsla() method in the client project is not recognized and gives an error. I could not replicate the code you have in the book, nor the following:

builder.Services.AddTransient(typeof(IDataPortal<>), typeof(DataPortal<>));

builder.UseCsla((c) =>
c.DataPortal().DefaultProxy(typeof(Csla.DataPortalClient.HttpProxy), "http://localhost:57410/api/DataPortal"));

The same thing happens if I load the Csla.Blazor.WebAssembly dependency in the client project. Although the solution compiles, when executing var app = builder.Build();, it gives the following error:

System.AggregateException: 'Some services are not able to be constructed (Error while validating the service descriptor 'ServiceType: Csla.ApplicationContext Lifetime: Scoped ImplementationType: Csla.ApplicationContext': Unable to resolve service for type 'Microsoft.AspNetCore.Components.Authorization.AuthenticationStateProvider' while attempting to activate 'Csla.Blazor.WebAssembly.ApplicationContextManager'.)

Is there any documentation that allows me to see the latest changes from version 5 to 7 and also where I can get the books you mention in your book, Using CSLA: ASP.NET Core book"?

Thanks in advance

[rockfordlhotka]

In the book I might have been running the data portal in local mode, so the logical server-side code actually runs on the client and there is no app server.

If you configure the data portal for local mode, then yes, the DAL types need to be registered and deployed to the client.

If you configure the data portal for remote mode with an app server, then the DAL types should only be registered (and often deployed) on the app server.

Is there any documentation that allows me to see the latest changes from version 5 to 7 and also where I can get the books you mention in your book, Using CSLA: ASP.NET Core book"?

Unfortunately not at the moment - I'm behind on my content creation work 😳

[ecaldentey]

Hello Rocky,

Finally, with your guidance, your book, extensive reading in various forum threads, and my new great friend Copilot, I managed to make my code work by injecting interfaces into DataPortal methods and declaring a class to handle the database connection, injecting it into the implementing class constructor, as suggested in post #3287.

Everything works well when running the code with the DataPortal configured in local mode, i.e., with the following statement in the Program.cs file of the client project:

builder.Services.AddCsla();

However, when I run it with the DataPortal configured to operate remotely, i.e., with the following configuration:

builder.Services.AddCsla(options => options
.AddBlazorWebAssembly()
.DataPortal(dpo => dpo
.UseHttpProxy(hpo => hpo
.DataPortalUrl = "https://localhost:7211/api/DataPortal")));

An error occurs when invoking the PostAsync method in the DataPortalController since the following line returns an error:

return base.PostAsync(operation);

To identify where the error occurs, I enabled your Csla.AspNetCore project, and the error occurs in:

  using (var reader = new BinaryReader(serializationStream))
  {
    var totalCount = reader.ReadInt32();
    for (var counter = 0; counter < totalCount; counter++)
    {

System.InvalidOperationException: 'Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.'

This exception was originally thrown at this call stack:
[External Code]
Csla.Serialization.Mobile.CslaBinaryReader.Read(System.IO.Stream) in CslaBinaryReader.cs
Csla.Serialization.Mobile.MobileFormatter.Deserialize(System.IO.Stream) in MobileFormatter.cs
Csla.Server.Hosts.HttpPortalController.InvokePortal(string, System.IO.Stream, System.IO.Stream) in HttpPortalController.cs

Copilot Answer:

This error happens because the application is trying to perform a synchronous operation, specifically a read operation, on a stream. However, synchronous operations are disallowed in this context.
This might be happening because the serializer.Deserialize(requestStream) method is being called synchronously. In ASP.NET Core 3.0 and later, synchronous I/O operations are disabled by default. This is to prevent thread pool starvation that can be caused by blocking calls. If your application attempts to make a synchronous I/O operation, it will throw a System.InvalidOperationException with the message "Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead."
To fix this issue, you could try to use the asynchronous version of the Deserialize method if it's available. If it's not, you might need to enable synchronous operations by setting AllowSynchronousIO to true in your Kestrel server options. However, this is generally not recommended as it can lead to performance issues. It would be better to refactor your code to use asynchronous operations where possible.
If the problem persists, additional information such as the implementation of the Deserialize method and the configuration of your Kestrel server would be helpful in diagnosing the issue.

Can you guide me on where my error might be? Am I missing to define any configuration?

Thanks in advance.

[rockfordlhotka]

You need some configuration in the Program.cs of the server project, just like there is in the BlazorExample server project.

csla/Samples/BlazorExample/BlazorExample/Server/Program.cs

Line 41 in 6d159d2

// If using Kestrel:

[ecaldentey]

That last piece of information did the magic :-)

Now begins the great journey of migrating all the relationships in the object graphs, Root/Child, etc., with their transactions and unit of work... but I already understand the essence of the new CSLA framework logic... I think :-)

Thank you very much