i'm piecing together EF and DI, i have a beginners understanding in it and im trying to solve for the following (in the one solution);
I have a web app (blazor web assembly) which has two projects (Client / Server)
I have a separate console app which will run off a service bus queue and needs to interact with the EF model in the server project
The solution is multi-tenant, so i send the client ID as a part of the request to the console app which will tell the app (and dbContext) which tenant DB to connect to
i have added the server project reference to the console app, and what i have the console app currently listening to a service bus queue and executing the required processing with dummy stub data.
what i need help with is how to setup the console app in .net6.0 to;
establish a transient DI database dbContext which uses the other project EF model AND establishes a tenant db connection on each execute (service bus post)
as a result of the processing i may need to also send a request to another service bus queue for other processing / actions / etc.
so i'm assuming a singleton service for that....???
i know the model, just not sure on how to code...
it's fairly simple and would probably take a dev about 15 minutes to configure... i'm not a good dev though :D
Related
I am using ServiceClient to access data in dataverse from a c# application. The application is a worker service and the service client is injected into the application using dependency injection as a singleton. I am seeing the service client cache results. Is there a work around for this. If I update the record in dataverse my application continues to pull the old data.
It appears since my context was a singleton I needed to detatch any records that I may have already queried.
I have a web app that uses SignalR with Redis scale-out (allegedly) and hubs, and that works fine. Now I need a worker role to be able to send messages to all connected clients but I'm not sure how to do it. I also have a console application that serves as a test app which runs the methods immediately that the worker will run periodically.
Hosting a web server within the worker or console app seems odd, but that's mostly I've found so far. Talking to the web app seems odd also. Shouldn't it be able to just post a message to Redis and all the subscribers pick it up?
This is the code I'm using. I copied the UseRedis call and the handleExecutedAction pretty much verbatim from the web app. It doesn't throw or anything but the message doesn't get to the web client:
GlobalHost.DependencyResolver.UseRedis(new RedisScaleoutConfiguration("...", "..."));
var hubContext = GlobalHost.ConnectionManager.GetHubContext<WebUI.EventHub>();
hubContext.Clients.All.handleExecutedAction(new Action { Type = "testing" });
I used this method (the context) after finding this page. I know the client is working because other messages come through from the web app, just nothing from the console app...
I was developing a simple Spring MVC application that invokes a Web Service over a JMS trasport. I need to deploy it on websphere application server. Everything seems to work fine when I reference the remote connection factory directly from my application, and even seems to work properly when I try to use a local JNDI Queue connection factory on my WAS, but then, I cannot shutdown my server.
It seems to be because its connections pool keeps locked by somebody. It never invokes Session.close over JMS session (it is managed by JAX-WS server framework, in this case Apache Axis2). I have done the same from an even simpler spring MVC application (just #Controller and views) and it stops fine. The application that makes pool to be locked just includes a more complex context with persistence and transaction management (annotation-driven).
Do you think that this transaction mananagement could affect JMS session management? Somebody have ever found a JMS connection pool locked by an spring application?
Thanks.
Regards.
That was the solution to avoid locking. We removed ServletContext.close, so our server can find the references to used resources, and can release connections on pool.
I have an ASP.NET Webform which currently calls a Java WebService. The ASP.NET Webform is created/maintained inhouse, whereas the Java WS is a package solution where we only have a WS interface to the application.
The problem is, that the Java WS is sometimes slow to respond due to system load etc. and there is nothing I can do about this. So currently at the moment there is a long delay on the ASP.NET Webform sometimes if the Java-WS is slow to respond, sometimes causing ASP.NET to reach its timeout value and throw the connection.
I need to ensure data connectivity between these two applications, which I can do by increasing the timeout value, but I cannot have the ASP.NET form wait longer than a couple of seconds.
This is where the idea of a queuing system comes into place.
My idea is, to have the ASP.NET form build the soap request and then queue it in a local queue, where then a Daemon runs and fires off the requests at the Java-WS.
Before I start building something from scratch I need a couple of pointers.
Is my solution viable ?
Are there any libraries etc already out there that I can achieve this functionality with ?
Is there a better way of achieving what i am looking for ?
You can create a WindowsService hosting a WCF service.
Your web app can them call the WCF methods of your Windows Service.
Your windows service can call the java web service methods asynchronously, using the
begin/End pattern
Your windows service can even store the answers of the java web service, and expose them through another WCF methods. For example you could have this methods in your WCF service:
1) a method that allows to call inderectly a java web service and returnd an identifier for this call
2) another method that returns the java web service call result by presenting the identifier of the call
You can even use AJAX to call the WCF methods of your Windows Service.
You have two separate problems:
Your web form needs to learn to send a request to a service and later poll to get the results of that service. You can do this by writing a simple intermediate service (in WCF, please) which would have two operations: one to call the Java service asynchronously, and the other to find out whether the async call has completed, and return the results if it has.
You may need to persistently queue up requests to the Java service. The easiest way to do this, if performance isn't a top concern (and it seems not to be), is to break the intermediate service in #1 into two: one half calls the other half using a WCF MSMQ binding. This will transparently use MSMQ as a transport, causing queued requests to stay in the queue until they are pulled out by the second half. The second half would be written as a Windows service so that it comes up on system boot and starts emptying the queue.
you could use MSMQ for queuing up the requests from you client.
Bear in mind that MSMQ doesn't handle anything for you - it's just a transport.
All it does is take MSMQ messages and deliver them to MSMQ queues.
The creation of the original messages and the processing of the delivered messages is all handled in your own code on the sending and receiving machines: the destination machine would have to have MSMQ installed plus a custom service running to pick them up and process them
Anyway there is a librays for interop with MSQM using JAVA : http://msmqjava.codeplex.com/
Another way could be you can create a queue on one of your windows box and then create a service that pick up the messages form the Queue and foreward them to the Java service
I want to design a bullet-proof, fault tolerant, DB driven web application and was wondering on how to architect it.
the system will have a asp.net UI, web services middle tier and SQL2005 back end. The UI and Services will communicate using JSON calls.
I was wondering on how to ensure transactions are committed and if not for any error to bubble up and be logged. ideally the action to be retried a couple times after 5 minute intervals, like an email app does.
I was planing to use try catch blocks in SQL and was wondering what the interface (or contract if you will) would look like between the SQL stored procs and the Services that call them would look/ function. this interface will play 2 roles one is to pass params for the proc to function and return expected results. the next will be for the proc to return error information. maybe somethign like error number and error message.
my quagmire is how to i structure this intelligently so that the services expect and react accordingly to both data and error info returned from procs and handle each accordingly?
is there a framework for this because it seems very boiler plate?
You might consider looking into SQL Server Service Broker:
http://msdn.microsoft.com/en-us/library/ms345108%28v=sql.90%29.aspx
The unique features of Service Broker
and its deep database integration make
it an ideal platform for building a
new class of loosely coupled services
for database applications. Service
Broker not only brings asynchronous,
queued messaging to database
applications but significantly expands
the state of the art for reliable
messaging.