Develop Reference

Managing DbContext lifetime in ASP.NET Core SignalR

I have implemented an ASP.Core SignalR Application.
A shared hub class is invoking a signal to all its client on every 10 seconds
from class SharedHub (this class is not inherited from Hub it has logic to get IHubContext to invoke)
public void Tick(){
var time = _context.table.time;
invoke('tick', time.tick);
}
Also in the same class once a new connection established a method called to update database
public void UpdateSocketConnection(int connectionId){
var connection =_context.connection;
connection.id = connectionId;
_context.saveChanges();
}
Problem with this implementation is if the connection is currently calling Tick() method and also a client connected the same time. _context throws an error saying:
_context in use.
(I'll update exact error message once I reproduce).
What I have done ?
I have implemented a factory method to get a new instance of _context on top of every method
public void Tick(){
var time = factory.GetContext().time;
invoke('tick', time.tick);
}
public void UpdateSocketConnection(int connectionId){
var context = Factory.getContext();
var connection =context.connection;
connection.id = connectionId;
context .saveChanges();
}
This actually solved the problem. But it seems not the right thing to do. I am not sure of the performance when getting a new context every time on top of every method. this seems bad practice.
I want to know what are the possible implementation for this scenario.

In the first approach DbContext is shared between operations at the same time and it cause error and unexpected result. To avoid create and dispose DbContext every time in the second approach, DbContextPooling can help performance.
A pool of reusable instances can be created. Instead of disposing an instance, it returns to the pool and resets the instance to its default state. So instead of creating a new instance every time, the code will first check if there is an instance available in the pool or not.
You can enable DbContextPooling in Configure method in startup class:
services.AddDbContextPool<YourContext>(options => options.UseSqlServer(connection));
The default pool size value is 128. Read this article for more info.

Using static methods and static classes in web applications - Should it be avoided?

We have a MVC application with a traffic of about 800 users per day, lately we have observed that our App Pool is getting stopped on its own. Going to the logs we have found MemoryOutOfException. We were not able to figure it out why this might be happening so we did a code review. During code review we found out that we have static classes, static methods / Extension methods. We don't have any static variables and we are using using block to dispose DbContext.
So is it possible that our static class/ static methods be the reason for memory issues ?
How are instances created inside static methods and classes disposed ? Are they collected by GC ?
Please suggest what more can we do to figure out the issue.
EDIT
Sorry for not sharing any code.
I want to understand the lifecycle of static class in web application. Can they create problem if I am doing complex operation that takes memory ?
For example if I translate my Domain model to View Model inside my static class like so :
public static class PersonTranslator{
public static PersonVM (this Person p)
{
return new PersonVM{
Name = p.Name,
//etc...
//lots of property here
}
}
}
Is it a good practice or I should just use normal classes rather going for
extension methods. Can code like this create issues ?
Thanks
EDIT 2:
Our db context is implemented in base class and all the data access class derieve from it. I think (and I may be wrong ) that something is wrong here.
public class DataAccessBase : IDisposable
{
protected ApplicationDataContext dataContext = null;
public DataAccessBase()
{
dataContext = new ApplicationDataContext();
}
public DataAccessBase(ApplicationDataContext dataContext)
{
if (dataContext == null)
dataContext = new ApplicationDataContext();
this.dataContext = dataContext;
}
~DataAccessBase()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
// The bulk of the clean-up code is implemented in Dispose(bool)
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
// free managed resources
}
// get rid of unmanaged resources
if (dataContext != null)
{
dataContext.Dispose();
}
}
}

Frankly it could be anything:
How much RAM does your server have?
How many other sites are running on the server?
How extensively are you using caching?
What kind of session storage are you using and what are you allowing users to store in a session?
At this point, Id suggest profiling your application with the Performance Wizard. Typically though you would have done this prior to production and have instrumented your application because how else can you decide what size server / VM your app needs?
.NET memory allocation gives you insight into the memory management of
your application because it analyzes every object in memory from
creation to garbage collection. The monitor can work in two different
ways. The first and less impactful is through sampling. It can also
take a much deeper look through instrumentation where code is added
into the binary to keep track of memory work.
You could also consider using Performance Counters and perfmon on the server. At the very least you should be getting alerts prior to the AppPool being dropped.i.e. at 80% of capacity for example.
It might even be that there is no "code" problem. You may have just underestimated what kind of resources are required to run your site (factoring in growth patterns) because as above without performance profiling pre-production it could have only have been a guess as to what you actually need.

Nhibernate sessionPerThread

I am creating entities in with multiple thread at the same time.
When i do this in sequence order (with one thread) everything is fine, but when i introduce concurrency there are pretty much always new exception.
i call this method asynchronously:
public void SaveNewData(){
....DO SOME HARD WORK....
var data = new Data
{
LastKnownName = workResult.LastKnownName
MappedProperty = new MappedProperty
{
PropertyName = "SomePropertyName"
}
};
m_repository.Save(data);
}
I already got this exception:
a different object with the same identifier value was already
associated with the session: 3, of
entity:TestConcurrency.MappedProperty
and also this one:
Flushing during cascade is dangerous
and of course my favourite one:
Session is closed!Object name: 'ISession'.
What i think is going on is: Everythread got same session (nhibernateSession) and then it... go wrong cos everything try to send queries with same session.
For nhibernate configuration i use NhibernateIntegration with windsor castle.
m_repository.Save(data) looks like:
public virtual void Save(object instance)
{
using (ISession session = m_sessionManager.OpenSession())
{
Save(instance, session);
}
}
where m_sessionManager is injected in constructor from Castle and it is ISessionManager. Is there any way how to force this ISessionManager to give me SessionPerThread or any other concurrent session handling ?

So i researched and it seems that NHibernateIntengrationFacility doesnt support this transaction management out of the box.
I solved it when i changed to new Castle.NHibernate.Facility which supersede Castle.NHibernateIntegration - please note that this is only beta version currently.
Castle.Nhibernate.Facility supports session-per-transaction management, so it solved my problem completely.

Why Call OrganizationServiceProxy.Dispose()?

What are the ramifications of not calling .Dispose() on an OrganizationServiceProxy object?
Sometimes, during testing, code crashes before the object can be disposed; does this mean that a service channel is left open for all eternity?
I have the same question about OrganizationServiceContext, which I had not been disposing until reading this today.
/* Synchronizes with CRM * */
public class CRMSync
{
[ThreadStatic] // ThreadStatic ensures that each thread gets a copy of these fields
private static OrganizationServiceProxy service;
[ThreadStatic]
private static Context linq;
/* Tries to connect to CRM and return false if failure - credentials arguments */
private bool Connect(string username = #"username", string password = "password", string uri = #"orgUrl/XRMServices/2011/Organization.svc")
{
try
{
var cred = new ClientCredentials();
cred.UserName.UserName = username;
cred.UserName.Password = password;
service = new OrganizationServiceProxy(new Uri(uri), null, cred, null);
service.EnableProxyTypes(); // this has to happen to allow LINQ early bound queries
linq = new Context(service);
var who = new Microsoft.Crm.Sdk.Messages.WhoAmIRequest(); // used to test the connection
var whoResponse = (Microsoft.Crm.Sdk.Messages.WhoAmIResponse)service.Execute(who); // this fails if not connected
}
catch (Exception e)
{
Log(e.Message); // Write to Event Log
return false;
}
return true;
}
}
Is there another way to use the same OrganizationServiceContext and OrganizationServiceProxy in multiple methods?
I plan to use this destructor to dispose the OrganizationServiceProxy and OrganizationServiceContext:
~CRMSync()
{
if (service != null)
service.Dispose();
if(linq!=null)
linq.Dispose();
}
EDIT
This is the method that is called by the service OnStart
/* Called by CRMAUX.OnStart when it is time to start the service */
public async void Start()
{
this.ProcessCSVFiles(); // Creates a ThreadPool thread that processes some CSV files
this.ProcessCases(); // Imports cases into CRM from a db (on this thread)
var freq = 0;
ConfigurationManager.RefreshSection("appSettings");
var parse = int.TryParse(ConfigurationManager.AppSettings["Frequency"], out freq);
await System.Threading.Tasks.Task.Delay((parse) ? freq * 1000 * 60 : 15000 * 60); // 15 minutes default or user defined
Start(); // Start again after the wait above
}
This is the Windows service
public partial class CRMAUX : ServiceBase
{
private CRMSync crmSync;
public CRMAUX()
{
InitializeComponent();
}
protected override void OnStart(string[] args)
{
ConfigurationManager.RefreshSection("userSettings"); // Get the current config file so that the cached one is not useds
if (TestConfigurationFile())
{
crmSync = new CRMSync();
Thread main = new Thread(crmSync.Start);
main.IsBackground = true;
main.Start();
}
else //The configuration file is bad
{
Stop(); // inherited form ServiceBase
return;
}
}
protected override void OnStop()
{
}
/* Checks the configuration file for the necessary keys */
private bool TestConfigurationFile()...
}

The OrganizationServiceProxy is a wrapper around a WCF Channel which utilises unmanaged resources (sockets etc.).
A class (our proxy) that implements IDisposable is essentially stating that it will be accessing unmanaged resources and you should therefore explicitly tell it when you're finished with it rather than just allowing it to go out of scope. This will allow it to release the handles to those resources and free them up for use elsewhere. Unfortunately our code isn't the only thing running on the server!
Unmanaged resources are finite and expensive (SQL connections are the classic example). If your code executes correctly but you don't explicitly call dispose then the clean up of those resources will be non-deterministic which is a fancy way of saying the garbage collector will only call dispose on those managed objects "eventually", which will as stated in turn clean up the unmanaged resources they're holding onto. This will hurt scalability of your application and any other services running on the same hardware that might be in contention with you for those resources. That's the best case scenario, if an exception occurs at any point in the stack subsequent to those resources being acquired they will not be released, ergo a memory leak and fewer resources available for use elsewhere.
Wrapping your code in a using statement is syntactic sugar as this compiles down to the proxy being wrapped in a try/finally with the dispose being called in the finally.
In terms of using the proxy/context across multiple methods you should take a look at the Unit of Work pattern. The OrganizationServiceContext is exactly that, something that you apply changes to over the course of a request (likely across multiple method calls) and then submit to the datastore (CRM) at the end when done, in our case using context.SaveChanges().
Where are you using this code as I'm curious to know what you're looking to achieve with the use of the [ThreadStatic] attribute? If it's within an IIS hosted application I don't think you'll see any benefit as you don't manage the thread pool so the proxy still only has a lifetime matching the HttpRequest. If this is the case there are several better ways of managing the lifetime of these objects, dependency injection frameworks and a HttpRequest lifetime behaviour being the obvious one.

If your app crashes, the operating system will automatically reclaim all your resources, i.e. close all network ports, files etc. So there's nothing kept open forever. Of course, on the server side something unexpected can happen if it is not handled properly and the app crashes in the middle of a request. But that's what transactions are for, such that the state of the server data is always consistent.

Management of Static Global Unmanaged Resources in Multithreaded App

We've run into a resource management problem that we've been struggling with for several weeks now and while we finally have a solution, it still seems weird to me.
We have a significant amount of interop code we've developed against a legacy system, which exposes a C API. One of the many peculiarities of this system is that (for reasons unknown), the "environment", which appears to be process-scoped must be initialized prior to the API being consumed. However, it can only be initialized once and must be "shutdown" once you're finished with it.
We were originally using a singleton pattern to accomplish this but as we're consuming this system inside an IIS hosted web service, our AppDomain will occasionally be recycled, leading to "orphaned" environments that leak memory. Since finalization and (apparently) even IIS-recycling is non-deterministic and hard to detect in all cases, we've switched to a disposal+ref counting pattern that seems to work well. However, doing reference counting manually feels weird and I'm sure there's a better approach.
Any thoughts on managing a static global disposable resource in an environment like this?
Here's the rough structure of the environment management:
public class FooEnvironment : IDisposable
{
private bool _disposed;
private static volatile int _referenceCount;
private static readonly object InitializationLock = new object();
public FooEnvironment()
{
lock(InitilizationLock)
{
if(_referenceCount == 0)
{
SafeNativeMethods.InitFoo();
_referenceCount++;
}
}
}
public void Dispose()
{
if(_disposed)
return;
lock(InitilizationLock)
{
_referenceCount--;
if(_referenceCount == 0)
{
SafeNativeMethods.TermFoo();
}
}
_disposed = true;
}
}
public class FooItem
{
public void DoSomething()
{
using(new FooEnvironment())
{
// environment is now initialized (count == 1)
NativeMethods.DoSomething();
// superfluous here but for our purposes...
using(new FooEnvironment())
{
// environment is initialized (count == 2)
NativeMethods.DoSomethingElse();
}
// environment is initialized (count == 1)
}
// environment is unloaded
}
}

I'm jumping in feet first here as there are a lot of unknowns about you particular code base, but I'm wondering is there is any mileage in a session based approach? You could have a (thread safe) session factory singleton that is responsible for ensuring only one environment is initialised and that environment is disposed appropriately by binding it to events on the ASP.NET AppDomain and/or similar. You would need to bake this session model into your API so that all client first established a session before making any calls. Apologies for the vagueness of this answer. If you can provide some example code perhaps I could give a more specific/detail answer.

One approach you might want to consider is to create an isolated AppDomain for your unmanaged component. In this way it won't be orphaned when an IIS-hosted AppDomain is recycled.