EF 4.1 POCO: DbSet<T>.Add becomes slower the more entities are added to context RRS feed

  • Question

  • Good morning,

    i have an application that creates entities from a message Queue and inserts them into a database. When the application starts it adds about about 20 per second. However, the longer the app runns the slower the DbSet<T>.Add(E e) gets. After a day i'm down to 1 per second.

    The Loop that inserts is really simple and only does:

    Entity myE = new entity() { bla=foo, ...};


    I call SaveChanges every 10 seconds.


    Any ideas?

    Best regards,


    Monday, October 10, 2011 10:28 AM

All replies

  • Hi


    If you keep  your ObjectContext alive for long time it keeps on growing on memory and causes performance issues..I guess this is what happening in your case.

    What you suppose to do is

    using(ObjectContext s = new ObjectContext())




    this make sures every time you call on SaveChanges it disposes ObjectContext...

    Hope this helps you....


    If this post answers your question, please click "Mark As Answer". If this post is helpful please click "Mark as Helpful".
    • Edited by Kris444 Monday, October 10, 2011 11:28 AM Format
    Monday, October 10, 2011 11:28 AM
  •  In fact this seems to be the problem.

    The object context is injected via ioc in the constructor, hence creating a new context is not an easy option. Would a migration from poco to entityObject solve the problem ?



    • Edited by armin o Monday, October 10, 2011 1:04 PM
    Monday, October 10, 2011 1:04 PM
  • No, bt you should be able to instruct your ioc container to put a lifetime on your context or to generate a new context each time it is requested.
    Monday, October 10, 2011 2:13 PM
  • For guidance on how to manage DbContext lifetime, see the following topic (Context \ Lifetime section)

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, October 11, 2011 7:05 AM

    I entirely disagree.

    This is not a lifetime issue, but a shortcoming in the implementation of EF4.1 DbContext.

    Following a domain driven design approach, the context is injected into an (application layer) service, which itself is injected into the QueueProcessor that simply listens what is sent to the Q in order to persist the message.

    The Queue Processor itself has no access to the Context. Recreating the context directly in the Queueprocessor is a design violation (although for now it solves the problem).


    Why the DbSet<T>.Add(E e) becomes slower by every object persisted to the DB is still beyond me. After a call to savechanges() the Context should be as good as new.

    I consider this to be an erratic behaviour in EF4.1 rather than a lifetime issue.



    Tuesday, October 11, 2011 9:56 AM
  • Instead of injecting the Context directly, you could also inject a Context factory or a custom context which is aware of your transactions.
    Tuesday, October 11, 2011 10:07 AM
  • Hi,

    I am writing to check the status of the issue on your side. Would you mind letting us know the result of the suggestions?

    If you need further assistance, please feel free to let me know. I will be more than happy to be of assistance.

    Have a nice day.

    Alan Chen[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, October 14, 2011 1:37 AM