Context for the entire database

[Fiend]

Hello,

I am a developer who has just come on to a project that is using dotConnect for Oracle 6.5 (using a LINQConnect context model) along with MVC.

The previous dev team used a single context model that encompasses the entire database. We have ~125 tables and over 100 stored procs all of which are defined within the context model. This context is getting instantiated on any DB call and it seems pretty expensive. The model context designer .cs class is nearing 100,000 lines of code.

I have never used dotConnect for Oracle, but it seems to me a better way of doing things would have been to at least split the model up into several context models based on different functional units within the website. The context instantiation would obviously be much more lightweight as the context would be pared down to just what is needed. Right now it takes a few seconds just to instantiate the context model... and this is on every DB call.. ouch.

We've also talked about caching the context within session for each user session so we don't have to instantiate the context on every single DB call (we briefly talked about a static instance of the context but it's not thread safe from what I've read so that seems to be a non-starter).

I just wanted to reach out to the community to get any input/ideas/suggestions you may have for improving the context architecture we've inherited. There are some major performance issues with the way it is currently designed. Would you say our ideas are sound? Has anyone run into similar issues and solved them in a different way?

Thanks in advance for any input any of you can give. It's greatly appreciated!

[MariiaI]

You can use separate models based on different functional units within the website, but this is safe only when there are no dependencies between the divided parts (e.g., associations, inheritance).
Perhaps some useful information can be found in this article:
http://craftycodeblog.com/2010/07/19/li ... -multiple/

As for the time needed to initialize a context, could you please specify what kind of mapping are you using - attribute or XML mapping?
In fact, it takes much time to get metadata while creating a DataContext. Also, the prepared mapping can be cached, but for attribute and XML mapping we do it in different ways.

Consider using one DataContext instance for a single Web request. In this case, if in this single Web request you query database several times, this should improve performance due to rarer context initializations.
We don't recommend to use one DataContext for one session, due to the fact that session can take quite a long time and may contribute to work with outdated data, etc.
The context lifetime is discussed, e.g., here (see the arguments for the 'per-request' approach in the second answer):
http://stackoverflow.com/questions/2724 ... t-re-usage

[Fiend]

Hi Mariial,

First, thanks for the info. That is definitely helpful. If we decide to split up our context, we would definitely split it up into self-contained units. It sounds like we don't want to store in session, but based on the second response to the second link, it sounds like since we have the whole database in one context to begin with, that would be a performance hit.... in effect we are already doing some of what he is arguing against doing. Every DB hit, we are initializing the entire DB in one context model.

If we had the context in session, we would be returning instantiated objects (or sets of objects) that are filled with data based on the "xxxxResult" partial classes from the context, right? Do these objects get cached in some way? Is that why you recommend against storing the context in session and why you would say data might be out of date if the context is stored in session? I was looking at the context model as more of a class just to get to the data and if it was in session, it would just provide the mechanism for getting to the data without having to instantiate it every time. Storing it in session would obviously have a big resource cost to it per session, so we were leaning towards just splitting the context up into self-contained functional units.

I have some other questions that may go off-track on a few things... caching, the mapping type, etc. Can I send you an email or you can send me one? I'll definitely return back to this thread with info once we have some sort of resolution.

[Fiend]

If I look at the Model Settings, the Mapping Mode is set to Attributes.

[Fiend]

In my second post, I should have said the "xxxResult" partial classes for stored procs and then instances of the table entities for everything else.

[MariiaI]

After the data for the entity classes has been received, it is cached and when working on a session for some time, the data in the database may change while the data in the cache will stay the same. The complex type objects returned by stored procedures and functions are not cached.

If you are using attribute mapping, the mapping source is created as a static field of the context, so it's initialized once. After that, metadata objects are created based on this static field, which should speed up metadata initialization. You can check whether your context has this field:

Code: Select all

private static MappingSource mappingSource = new Devart.Data.Linq.Mapping.AttributeMappingSource();

For more information about caching, the mapping types, please refer to:
http://www.devart.com/linqconnect/docs/Mapping.html
http://www.devart.com/linqconnect/docs/ ... eries.html

If you have any further questions, you could ask them on our forum in the corresponding sections or via our contact form.

[Fiend]

Mariial,

Thanks for the reply. I think we may be getting somewhere. That last bit of code you posted triggered it for me I think.

In our context .cs, that static mappingSource field is not getting created. We have a static method (GetMappingSource) there which is returning a new mappingSource every DB hit, but the mappingSource itself was not static.

I've tested out making the mappingSource a static field and passing that it into the context constructor and it seems to have fixed the issue. We're not returning a new mappingSource on every hit now and, initially at least, things seem to be working fine... and we don't have the expense of creating the new mappingSource on each hit now.

The only thing that concerns me is this: I created a new model while testing other avenues out and the wizard for generating the context model is what creates the GetMappingSource method which is returning the new mappingSource every time the class is instantiated. Could it be that since we are using 6.5 that this is was something that was enhanced in later versions? It seemed like you were expecting me to see that line of code you posted in your last post.... but as I've noted above it's not quite implemented that way in the version of dotConnect we are using. Let me know!

[MariiaI]

The 'GetMappingSource' method is generated when using XML mapping and, respectively, the static field 'mappingSource' in this case shouldn't be generated.
As you have said earlier, you are using attribute mapping. Thus, this issue could be, if you are using an old template to generate the code for your model. Another possible reason may be that you are using the 'POCO entity' template. This template generates LinqConnect-independent classes and doesn't generate attributes.

Please send us the full text of the used template or beginning of the context definition in the generated code (in particular, the GetMappingSource method), so that we are able to investigate this question.

[Fiend]

Mariial,

I've sent the requested info.

[MariiaI]

We have answered you by e-mail.