Sql – LINQ DeferredLoadingEnabled & DataLoadOptions relationship


I have had a road-block that has cascaded itself down to the situation described below. I haven't had much help with people answering my previous questions, (i think i have to learn to frame them better) but i hope someone can at least explain this to me (i am a newbie to LINQ and haven't had an opportunity as yet to read into it at any great length).

I'm using a Repository Model to access data through LINQ-to-SQL. I am trying to use 1 data-context declared as a public static so that i'm always using the same context.

Problem 1: webpages were loading with cached values immediately after saving changes. The changes were propagated to the db, but the datacontext was spitting out a cached copy of the object.

Workaround: Set ObjectTrackingEnabled = false on the datacontext.

Problem 2: Now, objects cannot lazy-load – all entities within the given object are null when i examine them during debugging.

Workaround: Set DeferredLoadingEnabled = false on the datacontext.

Problem 3: LINQ doesn't automatically set Immediate-loading for all entities associated to the given object.

Workaround: Explicitly configure LoadOptions for the datacontext and manually identify each associated entity by setting LoadWith<Object>(o => o.entity1), LoadWith<Object>(o => o.entity2), …, LoadWith<Object>(o => o.entityN).

Can some help me get past the caching problem without having to deal with the rest?

If not, can someone tell me if there's another way to set ImmediateLoadingEnabled (or something like that) on the data context, so that i don't have to explicitly state the loading options for all entities associated with all objects in my domain?

I'd really appreciate some feedback. If i'm asking questions without enough information or if you'd like an example, please let me know!

Thank you in advance!

Best Solution

You can't use a single context for a webapplication, as a webapplication is multithreaded (1 thread per request for example) and this would mean that multiple threads are using the same context. I.o.w.: you should use a system where for each request of data, you create a new context and use that for the query to execute, then dispose the context.