I am using the WCF Dataportal Proxy to run the data portal fetch methods on the server. I want to make use of the ConcurrencyMode in WCF but cannot see how to configure this in my server code. I have configured by xml but I believe I need to decorate the method in C# with
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,ConcurrencyMode = ConcurrencyMode.Multiple)]
Is it possible to do this?
I am not familiar with this option, what does it do?
I ask, because the data portal makes certain assumptions about the environment in which it runs - not many assumptions, but some - so if this option violates an assumption the results might be undesirable.
The answer to your question though, is that you'll need to create a custom host type. That is not very difficult, since the service contract is already defined - you just need to create a new implementation of the IWcfPortal interface.
Now if you need to set attributes on the service contract itself, that's a little harder since you'll need to create your own interface and implementation, and that will force you to create your own client-side proxy (obviously, because the existing proxy talks to an IWcfPortal).
But even that is entirely realistic - the data portal is completely flexible in this regard, as long as you understand both WCF and the data portal.
It basically allows the service to run multiple treads, i.e. so that a client can call the service several times on multiple treads, and the WCF service runs then async, rather than the default behaviour of sync. The single flag dictates how many instances of the service are created.
OK, that may be a problem, or maybe not.
The data portal assumes a synchronous service. You can't use async WCF channels with the data portal,. So this may work, but only if, from the client's perspective, the service is synchronous. If it is only async on the server, but the client call is blocked until completion, then you'd be OK.
The data portal also assumes each client call is handled by the server in an isolated context. That means either a single consistent thread (the default) or within a single HttpContext per request. Either way, Csla.ApplicationContext isn't threadsafe (just like the rest of CSLA and most of .NET), and it is stored on the thread or HttpContext.
I'm curious as to why you're wanting to develop a DataPortal proxy with this configuration. The settings you're applying are essentially creating a singleton service that requires you to manage all thread synchronization. From a scalability perspective, this isn't ideal, and as Rocky has already mentioned, parts of CSLA aren't threadsafe (which could cause you problems). Given what you say you're doing, why is the per-call setup not working for you?
Copyright (c) Marimer LLC