I'm using Simple Injector for IoC and Rebus, service bus, to dispatch events saved in multiple queues (topic).
Rebus needs to be configured with a new SimpleInjectorContainerAdapter for each queue.
var bus = Configure.With(new SimpleInjectorContainerAdapter(container))
In this configuration phase is not possible to pass the same instance of Simple injector container neither the same instance of container adapter (the container rises an error of multiple registration of IBus).
I'm also using SignalR as one of the events ' handlers to dispatch events to the clients.
Following this SignalR configuration tutorial I set up several hub and relative event notifier (one for each bounded context in the application).
Using the classical singleton pattern, as shown in the tutorial example, is easy to pass the same instance of notifier to the various instances of containers:
container.RegisterSingleton(Finishing.Notification.Notifier.Instance);
Now I would like to delegate the instance creation to the Simple Injector container (only one), so I started to follow this tutorial:
container.RegisterSingleton<Finishing.Notification.Notifier>();
container.Register(() => GlobalHost.ConnectionManager.GetHubContext<Finishing.Notification.NotificationHub>().Clients);
The issue is that, in this way, I will have n instance of notifier one for each container instance (deeply regrettable).
I know that I can solve this using a master container as Abstract Factory, but I'm looking for a more specific solution.
Thanks.
Now I would like to delegate the instance creation to the Simple Injector containers
(...)
The issue is this way I will have n instance of notifier one for each container instance.
So you would like for each container to create the singleton instance, but it is a problem that each container holds an instance of the singleton... isn't that a contradiction?
Related
I am using the Service Grid based on Apache Ignite .Net and I am seeking to implement the distributed tracing for requests spanning multiple Ignite services.
To implement that, I need to pass a request id (also known as correlation id) through the entire call chain. So I wonder if there is a way to transparently pass some context information from an Ignite service caller to the target Ignite service without wrapping the method arguments in some form of envelope? That would enable me to keep the method arguments clean.
I see that there is the void Execute(IServiceContext context) method that gives access to some context information on the receiving side. Is there a way to manipulate the context on the client side?
Thank you!
void Execute(IServiceContext context) method is invoked automatically whenever an instance of the service is deployed on a grid node, and ServiceContext instance is created inside the grid on service deployment, so it's not intended to be manipulated somehow from the client side.
In described case some kind of correlation id can be added to the service's methods signatures.
Just want to confirm my understanding is correct. If I use Single instance mode for a service:
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)]
and this service calls a class from another asssembly which has a static constructor, that constructor is only called the first time ther service is called? The constructor I am talking about sets up a fair number of AutoMapper maps, and I only want this overhead the first time the service is called.
Taking this further, If I have two different services, and they both us the shared class, am I correct that the static constructor is still only called once?
Best
Ray
There is no connection between InstanceContextMode and how many times static constructor is fired. Static constructor is called once per Application Domain. So if your services are hosted within one Application Domain then your constructor will be called once.
As far as I understand you use the contructor to register AutoMapper configuration... To me it is not a good approach. Assuming your services are hosted on IIS you would better create a Global.asax file and then run you mapping registration code in Application_Start method. Of cource you can wrap it in some static method first.
Hope it helps!
We're using Unity to provide dependency injection within the WCF service layer for our current project, and we have followed examples such as the following to write a service host factory, service host, service behaviour and instance provider:
http://avingtonsolutions.com/blog/post/2008/08/02/Uisng-Unity-with-a-WCF-Service.aspx
The solution works very successfully, but we have need to provide contextual resolution of objects on a per-request basis. So far, we have implemented this by creating a child container within the GetInstance method of the instance provider, adding the contextual registrations to the child container, and using the child container to perform the resolution of the service type. Some registrations in both containers use container controlled lifetimes.
As I do not know the lifetime of the child container, I have concerns about this methodology:
1) Does the child container go out of scope at the end of the GetInstance method and therefore get disposed leading to some of our our container resolved objects being disposed in the middle of our request?
2) Alternatively, does the parent container cling on to the child container for some period of time meaning that it will rapidly fill with child container instances in a high traffic environment?
Can anyone point me in the right direction?
I am using Wcf in Sharp Architecture. I have configured my project following northwind sample using WcfSessionStorage etc. I have a method in the wcf service that gets a list of business object using Repository<>.GetAll(). I am testing the service method using WcfTestClient. When the method is called the very first time, everything works fine. However on the subsequent call, I get the following exception on the Repository<>.GetAll() method
[System.ObjectDisposedException]
Session is closed!
Object name: 'ISession'
It seems like the NHibernate session gets disposed after each call. I have got around this problem by decorating my service with the following attribute
[ServiceBehavior( InstanceContextMode = InstanceContextMode.PerCall )]
public class WcfService : IWcfService
{
}
However this means, an instance of the service will be created on each call that in turn will create a new nhibernate session etc. In my scenario there is no need of creating a new service instance per call and I think its an expensive process and not the right solution. I would like to know what is the best practice in my scenario and how to get this thing work with creating a new service instace per call.
Thanks
Nabeel
The easiest way is to create a new instance every time and it's not an expensive process, because creating a new object in .NET is like 0.00000000000000001 second (I read that on Ayande's blog or somewhere).
I use Autofac DI in my projects and I usually make ISession as container scoped (one per request). And then every class that uses (directly or indirectly) ISession has to be container scoped or lower (factory scoped == every class usage get's a new instance). If a class that uses ISession is higer scoped (session scoped == singleton) you'll run into problems that you currently have.
If your service is singleton service:
At first run the service is created, this service uses ISession, which should be container scoped, and it is on the first run.
The next request to service (service is now created) has still a reference to created ISession (which was closed on previous end request), so now it's closed.
I don't recomend using the same ISession that you'll open/close (it's not recomended in the NHibernate documentation), just use container scoped (I do and I don't have any performance issues), or you should create ISession manually in every method in your service like:
using(ISession s = ISessionFactory.OpenSession())
using(ITransaction t = .....)
....
But that isn't nice at all...
Please take a look at my answer to my own similar question: WCF/S#arpArch: underlying ISession is closed after the first call within a request.
#dmonlord is right that the creation of additional session instances within the same request is very cheap in this case.
I have been trying to get up to speed on Named Pipes this week. The task I am trying to solve with them is that I have an existing windows service that is acting as a device driver that funnels data from an external device into a database. Now I have to modify this service and add an optional user front end (on the same machine, using a form of IPC) that can monitor the data as it passes between the device and the DB as well as send some commands back to the service.
My initial ideas for the IPC were either named pipes or memory mapped files. So far I have been working through the named pipe idea using WCF Tutorial Basic Interprocess Communication . My idea is to set the Windows service up with an additional thread that implements the WCF NamedPipe Service and use that as a conduit to the internals of my driver.
I have the sample code working, however I can not get my head around 2 issues that I am hoping that someone here can help me with:
In the tutorial the ServiceHost is instantiated with a typeof(StringReverser) rather than by referencing a concrete class. Thus there seems to be no mechanism for the Server to interact with the service itself (between the host.Open() and host.Close() lines). Is it possible to create a link between and pass information between the server and the class that actually implements the service? If so, how?
If I run a single instance of the server and then run multiple instance of the clients, it seems that each client gets a separate instance of the service class. I tried adding some state information to the class implementing the service and it was only retained within the instance of the named pipe. This is possibly related to the first question, but is there anyway to force the named pipes to use the same instance of the class that is implementing the service?
Finally, any thoughts on MMF vs Named Pipes?
Edit - About the solution
As per Tomasr's answer the solution lies in using the correct constructor in order to supply a concrete singleton class that implements the service (ServiceHost Constructor (Object, Uri[])). What I did not appreciate at the time was his reference to ensuring the service class was thread safe. Naively just changing the constructor caused a crash in the server, and that ultimately lead me down the path of understanding InstanceContextMode from this blog entry Instancecontextmode And Concurrencymode. Setting the correct context nicely finished off the solution.
For (1) and (2) the answer is simple: You can ask WCF to use a singleton instance of your service to handle all requests. Mostly all you need to do is use the alternate ServiceHost constructor that takes an Object instance instead of a type.
Notice, however, that you'll be responsible for making your service class thread safe.
As for 3, it really depends a lot on what you need to do, your performance needs, how many clients you expect at the same time, the amount of data you'll be moving and for how long it needs to be available, etc.