WebVella/WebVella-ERP

AsyncLocal null in different execution pipeline

Closed this issue · 2 comments

When using the technique described here (thanks @rumen-yankov for providing the example)

result = new EqlCommand("SELECT * FROM user").Execute();

DbContext.Current is null, due to DbContext.current.Value being null.

private static AsyncLocal<DbContext> current = new AsyncLocal<DbContext>();

Using AsyncLocal like this probably isn't recommended and it would be better if all the classes that relied on the DbContext took a reference to it in their constructor rather than try to look it up from AsyncLocal/ ThreadLocal/ HttpContext none of which I think would be perfect

Its possible and it fixes the problem - I know because I did it! (I couldn't move forward without this working)

Without automated tests its hard to know if its worked perfectly, all of my plugin code still ran and so on so I think its okay. Are you happy with this sort of approach? Do you want a pull request of it?

image

Hey Nathan, I agree that using AsyncLocal is not the best idea, but it eliminates that 'noise' added by passing as arguments all context, connections and transactions objects to methods or constructors.

I don't understand where you have problems with DbContext -> null , can you provide me a sample code ? In my example I create DbContext and make EqlCommand execute inside its scope.

Also I am OK with your suggestion to add context to constructor as additional argument to some classes and store it into them. Please create a pull request with changes you need i will merge them.

I don't understand where you have problems with DbContext -> null , can you provide me a sample code ? In my example I create DbContext and make EqlCommand execute inside its scope.

Thanks, the problem occurs when hosting WebVella inside a ASP.NET Core 3.1 Web Api running as a AWS Lambda function, using this technique

result = new EqlCommand("SELECT * FROM user").Execute();

current.Value ends up being null after its definitely assigned a value on what appears to be the right thread.

Also I am OK with your suggestion to add context to constructor as additional argument to some classes and store it into them. Please create a pull request with changes you need i will merge them.

Thanks this is the pull request.