2

I'm using Entity Framework 4.0 behind WCF services. My problem is that the memory used by the programm is growing a lot(start à 200Mo, and I stopped it at ~1.1Go.

How can I manage the cache? I mean, I've two datacontext, one of them is never used to read data, so can I disable the cache?

And for the other, can I specify the amount of space it cans use? Is there a way to monitor these resources? Is there a way to use less resources?

Thank you!

J4N
  • 15,713
  • 29
  • 136
  • 260

2 Answers2

4

First of all you should not use shared contexts. Create new context for each WCF request and dispose context before you end your operation processing! If you need some data caching do it outside of EF. EF itself is not supposed to be used as cache and there is no control of this behavior.

If you host your service in IIS you can configure AppPool recycling by specifying Private Memory Limit in advanced settings of the AppPool. But it will simply kill everything running in that AppPool.

Community
  • 1
  • 1
Ladislav Mrnka
  • 349,807
  • 56
  • 643
  • 654
  • Okay good to know, I was thinking it was a good idea. The thing is that the WCF service uses a "dataServer" which manage the connection to the database through EF, but with other things to. I was thinking it was a good idea, because like this if we have different users, we have only the time once in memory. And the data context isn't directly instantiated by the WCF call but at the launch of the program by the DataServer. One other advantage was that I'm listening to changes done to the context because I've to log them in a specific format for another program. – J4N Feb 02 '11 at 12:05
  • 2
    No I don't think that it is a good idea. If two clients connect at the same time and one will modify data, second will get modified data as well even the data wasn't commited yet. Moreover data are in memory once - it is true but every time you ask context for data it still execute DB query (unless you are using CTP5 and new Local proprety of DbSet or unless you query internal storage of the context) but by default it returns same unchanged instance. It doesn't work like cache. – Ladislav Mrnka Feb 02 '11 at 13:02
  • Yeah but in my case, every modification on an object that is attached to my server has to be saved, because I only receive object to save in my database so I cannot send changes that a client should not have. What I was meaning, it's that if I've, let's say one data context for each service and user, I will have fastly something like 80-100 datacontext(9 services, and I will normally have something 40-50 users using the program, but not in the same time) running instead of one. And I'm worried by the memory usage it will generate. – J4N Feb 24 '11 at 06:56
  • And I'm not sure it makes sql request again, because once, I added some row in my database through SQL Server Studio management, and request on my context weren't returning this field. – J4N Feb 24 '11 at 06:57
  • @J4N: The data context must be instantiated per call so you will only have as many contexts as you have concurrent requests. To your second comment: it is called identity map. Read again answer I linked. It is already explained there. EF always query DB again if you execute IQueryable query. – Ladislav Mrnka Feb 24 '11 at 08:32
1

What may be happening is that each call is creating a new context. Which remains in memory untill the connection timesout and the Garbage collection removes it.

  • Are you not disposing of the datacontext each time you use it?
  • Are you closing your connections from the client?
  • Are you using per call session mode?
Shiraz Bhaiji
  • 60,773
  • 31
  • 133
  • 239
  • no for the first question, yes for the two else. The dataContext is instantiated in a "DataServer" class, which is a singleton, used by WCF services and non-wcf services. And I've listener on the dataContext to know when sometime has been saved, to register this change in a specific format. – J4N Feb 02 '11 at 12:09
  • 1
    did you just say singleton? why...whhhhhyyyy do people still use singletons for database connections! the cost of opening and closing a db connection is miniscule - open late, close early, dispose correctly. singletons are evil. – RPM1984 Feb 03 '11 at 10:42