Entity Framework Memory Usage with a shared model

Question

I have an EF 4.2 EDMX model which I use in a multi-tenant application. I connect to about 100 databases that use the same EDM model. The first time each database is accessed, my working set goes up by ~12Mb, which seems mostly to be taken by the EDM metadata cache. The memory usage never goes back down. I would think the metadata/query cache could be shared since it is the same model.

Looking for suggestions to reduce my memory footprint, though I suspect I have no control over this.

NOTE: This same scenario is NOT a problem with CodeFirst (which we are using as well) but we have a lot of code that still uses the EDMX model and cannot convert it all right now.

Thanks!

Answer 1

I am adding to answer given by Arthur. I encountered an issue when I was using solution presented by Arthur. I had couple of Stored procedure mapped to EF Model and when I was executing them they were failing with following message.

System.InvalidOperationException was caught Message="The value of EntityCommand.CommandText is not valid for a StoredProcedure command. The EntityCommand.CommandText value must be of the form 'ContainerName.FunctionImportName'." Source="System.Data.Entity"

This was happening because of DefaultContainerName was not set when you initialize the context using MetadataWorkspace. For this to work correctly I made below changes.

I took slightly different approach to use EFConnection instead of reading form configuration since in case of multi-tenant DBs we would be not sotring connection string in config and passing it at runtime. Also used generics so that you can share implementations between different contexts. Also change above implementation to lock the thread only when it needs to i.e. when workspace is set.

public class SingleModelCachingObjectContext<T> : ObjectContext
{
    private static readonly object WorkspaceLock = new object();
    private static MetadataWorkspace _workspace;

    public SingleModelCachingObjectContext(string connectionString)
        : base(CreateEntityConnection(connectionString))
    {
        DefaultContainerName = typeof (T).Name;
    }

    protected override void Dispose(bool disposing)
    {
        if (disposing)
        {
            ((EntityConnection)Connection).StoreConnection.Dispose();
        }
    }

    protected static EntityConnection CreateEntityConnection(string connectionString)
    {
        if (_workspace == null)
        {
            lock (WorkspaceLock)
            {
                _workspace = new EntityConnection(connectionString).GetMetadataWorkspace();
            }
        }

        var builder =
            new DbConnectionStringBuilder
            {
                ConnectionString = connectionString
            };

        var storeConnection = DbProviderFactories.GetFactory((string)builder["provider"]).CreateConnection();
        storeConnection.ConnectionString = (string)builder["provider connection string"];
        return new EntityConnection(_workspace, storeConnection);
    }
}

Answer 2

I believe you can get what you want by caching the MetadataWorkspace yourself. This is essentially what DbContext does internally when using Code First. It's not that easy to do, but I worked out a quick prototype that I think should work.

The basic idea here is to let EF create a MetadataWorkspace once and then cache this and use it explicitly each time you need to create a context instance. This is obviously only valid if each context instance is using the same model--i.e. the same EDMX. To make this work I created a derived ObjectContext that handles the caching:

public class SingleModelCachingObjectContext : ObjectContext
{
    private static readonly object WorkspaceLock = new object();
    private static MetadataWorkspace _workspace;

    public SingleModelCachingObjectContext(string connectionStringName)
        : base(CreateEntityConnection(connectionStringName))
    {
    }

    protected override void Dispose(bool disposing)
    {
        if (disposing)
        {
            ((EntityConnection)Connection).StoreConnection.Dispose();
        }
    }

    private static EntityConnection CreateEntityConnection(string connectionStringName)
    {
        lock (WorkspaceLock)
        {
            if (_workspace == null)
            {
                _workspace = new EntityConnection("name=" + connectionStringName).GetMetadataWorkspace();
            }
        }

        var builder =
            new DbConnectionStringBuilder
            {
                ConnectionString = ConfigurationManager.ConnectionStrings[connectionStringName].ConnectionString
            };

        var storeConnection = DbProviderFactories.GetFactory((string)builder["provider"]).CreateConnection();
        storeConnection.ConnectionString = (string)builder["provider connection string"];

        return new EntityConnection(_workspace, storeConnection);
    }
}

You would then use this by creating a constructor on your DbContext class like so:

public MyDbContext(string connectionStringName)
    : base(new SingleModelCachingObjectContext(connectionStringName),
           dbContextOwnsObjectContext: true)
{
}

This is how it works. When you create an instance of your DbContext it in turn creates an instance of SingleModelCachingObjectContext passing in the name of the EF connection string that you want to use. It also tells DbContext to dispose of this ObjectContext when the DbContext is disposed.

In SingleModelCachingObjectContext the EF connection string is used to create a MetadataWorkspace and caches it in a static field once created. This is very simple caching and simple thread safety with a lock--feel free to make it more suited to your app's needs.

With the MetadataWorkspace obtained, the EF connection string is now parsed to obtain the store connection string and provider. This is then used to create a normal store connection.

The store connection and cached MetadataWorkspace are used to create an EntityConnection and then an ObjectContext that will use the cached MetadataWorkspace instead of using the normal caching mechanisms.

This ObjectContext is used to back the DbContext. The Dispose Method is overridden so that the store connection does not leak. When the DbContext is disposed it will dispose the ObjectContext, which will in turn call Dispose and the store connection will be disposed.

I haven't really tested this other than to make sure it runs. It would be very interesting to know whether or not it really helps your memory usage issues.

Answer 3

I don't have many experience with your problem but some suggestions of the top of my head:

Can you use ClearCache() method?

Also try using:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    modelBuilder.Conventions.Remove<IncludeMetadataConvention>();
}

Note that if you remove EdmMetadata table then there will be nothing checking if the database schema matches the model.

Try pre-generating views using T4 Template like DbContext Template or Poco generating template (http://blogs.msdn.com/b/adonet/archive/2010/01/25/walkthrough-poco-template-for-the-entity-framework.aspx).

Regards.