My understanding of .Net Remoting is limited (and probably imperfect), so please bear with me.
I've created a service that is hosting a singleton remoted object. It appears that the remoted object doesn't exist until a client attaches to the remoted object. Is this true? If so, how can I create an instance of the object in the service?
Thanks
Paul.
I'm pretty sure that there is no way to do this without calling a method on the object - It's just how server activation works.
You don't indicate why you need to do this, but I'd guess it is because the initialization of the singleton takes a while. Perhaps you could factor off the initialization into another class which is loaded at application startup, and this would reduce the singleon startup costs.
Thanks for you answer!
Actually, I found a way to get what I wanted. The key is that the object that is being hosted for remoting (as a singleton) needs to be a thin wrapper for an actual singleton object (as in Singleton<>). This way the base object will be created no matter what and the remotely hosted object will then be a wrapper for the internal singleton.
Related
I have a simple question. I'm newer with UnityContainer of Miscrosoft. I'm writing an ASP.NET MVC application with Unity for DI.
Have I a different CONTAINER for each user connected to my web app? Or the CONTAINER is the same for all users?
So if I resolve the life time of an object with ContainerControlledLifetimeManager does it mean that only for one user session this object is always the same?
I hope you understand.
Thanks,
Christian
Lifetime refers to the life of the object created by the DI process. Per request means each request gets its own object. If the object depends on the current user, querystring values on that request or values/presence of Request headers a PerRequest lifetime is appropriate. If you have settings that vary based on location of your service, for example, you saved values from web.config, then a the container is most likely created in global.asa and these objects can live as long as the container lives.
A concrete example:
You have a service as part of your site and you are migrating to vNext of that service. Users can opt-in by clicking a link that includes a parameter like &myService=vNext to see the new behavior. your Factory method uses the value of this parameter to select vNow or vNext for each request.
Here's some pseudo code to get you started:
container.RegisterInstance<IProductFactory>("enterprise", new EnterpriseProductFactory());
container.RegisterInstance<IProductFactory>("retail", new RetailProductFactory());
container.RegisterVersionedServiceFactory<IProductFactorySettings, IProductFactory>();
In this example RegisterVersionedServiceFactory is an extension method that does nothing but decide which of the IProductFactory instances to use for the current request. The factory provides the current instance (there are only two for the life of the service) to use for this request (thousands per seconds).
This pattern is what makes a very large site you probably used recently both very stable and very flexible. New versions of services are rolled out using this exact same pattern to help keep the site very stable.
If CORBA doesn't know about an object at compile time, how does CORBA identify an object passed to it at runtime?
How does it access that object at runtime?
CORBA uses Object References. For inter ORB (the middleware framework code running on your machine) communication, Interoperable Object References - IORs are used. These are string based and contain host, port, policies and other stuff.
You need an objects reference to act with it the CORBA way (location transparent, remote). This reference than is "narrowed" , i.e., the middleware connects to the remote site. After that, every call to the object is a remote call, but you won't notice than in the application as you can handle the object as it where local.
In a java web app, I need to call a remote soap service, and I'm trying to use a CXF 2.5.0-generated client. The soap service is provided by a particular ERP vendor, and its wsdl is monstrous, thousands of types, dozens of xsd imports, etc. wsdl2java generates the client ok, thanks to the -autoNameResolution flag. But at runtime it retrieves the remote wsdl twice, once when I create the service object, and again when I create a port object.
MyService_Service myService = new MyService_Service(giantWsdlUrl); // fetches giantWsdl
MyService myPort = myService.getMyServicePort(); // fetches giantWsdl again
Why is that? I can understand retrieving it when creating myService, you want to see that it matches the client I'm currently using, or let a runtime wsdl location dictate the endpoint address, etc. But I don't understand why asking for the port would reload everything it just went out on the wire for. Am I missing something?
Since this is in a web application, and I can't be sure that myPort is threadsafe, then I'd have to create a port for each thread, except that's way too slow, 6 to 8 seconds thanks to the monstrous wsdl. Or add my own pooling, create a bunch in advance, and do check-outs and check-ins. Yuck.
For the record, the JaxWsProxyFactoryBean creation route does not ever fetch the wsdl, and that's good for my situation. It still takes a long time on the first create(), then about a quarter second on subsequent create()s, and even that's less than desirable. And I dunno... it sorta feels like I'm under the hood hotwiring the thing rather than turning the key. :)
Well, you have actually answered the question yourself. Each time you invoke service.getPort() the WSDL is loaded from remote site and parsed. JaxWsProxyFactoryBean goes absolutely the same way, but once the proxy is obtained it is re-used for further invocations. That is why the 1st run is slow (because of "warming up"), but subsequent are fast.
And yes, JaxWsProxyFactoryBean is not thread-safe. Pooling client proxies is an option, but unfortunately will eat a lot of memory, as JAX-WS runtime model is not shared among client proxies; synchronization is perhaps better way to follow.
I've just run into a problem with a Quartz job that I'm invoking through Spring. My ExecuteInternal method had a [Transaction] attribute (because it does a load of DB calls) but when it runs, I get the 'No NHibernate session bound to thread' error.
Just wondering if that's because Spring.NET doesn't support the [Transaction] attribute in Quartz objects?
If not, that's fine... I can start a transaction manually, but wanted to check that it was the case, and not a silly error in my config somewhere.
[Update]
I figured it out actually. In the API docs, it says the preferable way to do this is use transactions on the service layer. My job was using DAOs to do its work, but my transactions are on my service layer, so I just called service methods from my job instead to do the same work (saving, updating records etc) since they already existed.
It also suggests that if you give the SchedulerFactoryObject a DbProvider, you can use transactions in the job itself, but when I did that it seemed to want to find my triggers configured in a special table in the DB (which I haven't set up since my triggers are all in XML) but that's possibly another way to do it.
Calling service methods works fine for me though.
The transaction attribute works using aop. Spring.NET creates an aop proxy for the decorated object. This proxy creates the session and starts the transaction.
In the ExecuteInternal method, you don't call the method on a proxy, but on the target itself. Therefore spring cannot intercept the call and do its transaction magic.
Your services are injected and therefore the transaction attribute works for them.
There's a good explanation in the spring docs on this subject: http://www.springframework.net/doc-latest/reference/html/transaction.html#tx-understandingimpl
How can I tell if the application my code is running in, is it in a service or an application? Why do I want to know this - I'm writing some code that is injected into the target application and that code has no way of knowing this information up front, so it has to work it out itself.
I cannot rely on any code being called from the service control manager, start, stop, or command line parameters.
I'm currently looking at GetConsoleWindow() which I hope will return NULL for a service (no console) and a window handle for any application (has a console). Not sure how valid this assumption is.
Any ideas for a better solution?
Search the current process id (GetCurrentProcessId) from the list of all running services (EnumServicesStatusEx)?
The assumption of GetConsoleWindow() is not valid.
It seems to me that you care about the context of your process more. Are you asking that if your program is running in service context or the user session? If so, use ProcessIdToSessionId() http://msdn.microsoft.com/en-us/library/aa382990%28v=VS.85%29.aspx to get your session id and you will know it.
Use WMI to query for Win32_Service instances where 'ProcessId=MyProcessid'. If there is no match, then your process is not a service.
Background on WMI app creation in C++ here.
For Windows Vista or later you can check the session id. Session 0 is reserved for services and non-interactive programs. User sessions start from 1.
Use OpenProcessToken to get the current process token. Then use CheckTokenMembership to see if the token includes the WinServiceSid well-known SID.