0

I have a few sets of data that are used by all users on site. I would traditionally look at caching these.

My current EF setup uses uow and repository patterns, so I tend to use context for a single transaction and dispose of it.

I plan to introduce some user interaction, so the data that was once entirely static, won't be as users will be allowed to add, delete and perhaps edit. I estimate that data will still only be refreshed every 2 minutes or so still a reasonable candidate for caching.

One option would be to keep with the cache idea, but retrieve and recache after each change. The biggest data sets will have around 5-10k rows.

Another option I thought of would be to have a single context for each data set which I keep open (static) and manage the data that way. I'm pretty new to EF so I'm not sure whether this is a good or bad idea but on face value it seems similar to the way caching would work. The only thing I'm unsure of is how to deal with the additional table data as I believe you can't track and use Include().

Anyone got advise on this?

4

2 に答える 2

0

You should definitely cache your data set, and dispose of your context after a single atomic transaction.

Alex James wrote a great blog post about this.

A couple quick points are that the context is not thread safe, and the object context could have leftovers from previous transactions which could alter results.

于 2012-08-15T11:35:34.367 に答える
0

Took a different approach to the problem.

Rather than per transaction, I now raise a uow per httprequestwhich solves the issue.

于 2012-09-19T17:34:20.580 に答える