Developer forum

Hello,

Please, have a look at the topic. Is it the same issue? If yes then it's related to TFS 83984 already fixed (Dynamicweb.Ecommerce 1.9.5 in nuget) and will be provided by upcoming DW9.9.1 soon.

BR, Oleg QA 

Hi Oleg,

The fix in TFS 83984 is only for the language bug I think? Or does it fix the concurrency errors that occur when a Dynamicweb.Ecommerce.Common.Context.GetCart(OrderContext orderContext) occurs too? Because those concurrency errors cause trouble for us with orders that spontaniously mis articles.

Greets Hans

Hi Hans

I do not know if we have a general problem with setcart. Not that we know of.

I can see that your code is 'webapi' and you are dealing with context - context uses session, and sessions in webapi is not supported by default in MVC - so question is if you have enabled session state for your webapi, if it is even a 'real' mvc webapi? Generally carts will not work at all when in a state with no session state.

BR Nicolai

Hello Nicolai,

The trouble we have is with GetCart, which for some reason calls SetCart seeing the stacktrace. 
We thought the concurrency exceptions where fixed in the latest release from a comment we saw in another forum post, but seeing these errors when setting the language 
makes us fear the problem still exists. (Especially since we are just setting the language here, and not manipulating the cart itself)  
Yeah we know we need sessions for our webapi, we fix that in our AfterBeginRequest observer: 

   [Subscribe(Standard.Application.AfterBeginRequest)]
#pragma warning disable CA1036 // Overload operator Equals and comparison operators when implementing System.IComparable
    public class ApplicationAfterBeginRequestObserver1 : NotificationSubscriber
#pragma warning restore CA1036 // Overload operator Equals and comparison operators when implementing System.IComparable
    {
        public override void OnNotify(string notification, NotificationArgs args)
        {
            if (!Dynamicweb.Environment.ExecutingContext.IsFrontEnd()) return;
 
            if (HttpContext.Current != null)
            {
                HttpContext.Current.SetSessionStateBehavior(System.Web.SessionState.SessionStateBehavior.Required);
            }
        }
    }

Greets Hans

Hi Hans

Having the need for setting the language in the context leads me to believe that there is something that should be done differently. Why is setting Context.Language needed? 

Setting Context.Language touches a session variable. It will also try to locate the Cart the user (from session) currently have (from session) and change the carts language to the one you are setting. 

I think we need to see more of your infrastructure to see what is going on. 

Also - are you sure that your session implemenation in global.asax is up-to-date? Seems like 'old' times session implementation for webapi - I believe using the System.Web.SessionState.IRequiresSessionState marker interface is a more modern approach, see https://docs.microsoft.com/en-us/dotnet/api/system.web.sessionstate.irequiressessionstate?view=netframework-4.8

public class SomeController : ApiController, IRequiresSessionState

BR Nicolai

Strike this: 

public class SomeController : ApiController, IRequiresSessionState

I think your session handling is the issue. Having anything with sessions (or Ecommerce.Common.Context) in your webapi is a problem as they are designed to be stateless. So you might need to implement a handler that supports the IRequiresSessionState.

BR Nicolai

Hi Nicolai,

Setting the language is the workaround for the bug (that will be fixed in the coming release) that a groups subgroups names are not in the correct (groups) language, and we should be able to remove that once that release is out. Remains the issue that any time we try to get the cart in backend code these same errors sometimes occur..

We will take a look at your alternative for the sessionstate, but I do not think it will make a difference with the Concurrency errors.

Greets Hans

Hi Nicolai,

Yeah, tried it but had no Session any more. Our HttpContext.Current.SetSessionStateBehavior(SessionStateBehavior.Required) does work though, and we used to have it in the Global.asax, but since that is no longer available we have moved it to the beginrequest observer. Is it your opinion that it can still cause our concurrency issues when we try to access the current order in our api calls?

Greets hans