ansaurus

Question

Strange behaviour with StructureMap / ASP.MVC / Visual Studio / LinqToSql

Answer 1

A:

Add:

MultipleActiveResultSets=True

To the end of your connection string (assuming MSSQL 2005+)

To do this for your linq context: Open the properties tab -> Expand Connection -> Click the "..." on 'Connection String' -> 'Advanced' -> 'MultipleActiveResultSets' -> true.

I solved this one myself today and my architecture is almost identical (save for unity instead of structure map). Including the two controllers being loaded via JS!

DaRKoN_ 2009-03-16 12:16:41

@DaRKoN - thanks. Do you have any more explanation for why this is the solution? ie what LinqToSql is doing? I would expect a linq query to open the reader and close it. There should be no readers open on a connection. There are no synchronous data calls either, it's all within the single thread.

Tim Peel 2009-03-16 12:37:46

I'm likely wrong, but due to dependency injection, the two controller actions are sharing the same datacontext. The JS requests them both virtually at the same time, so there is a chance a request is still open when the other request comes in. Id like to hear your thoughts on this too

DaRKoN_ 2009-03-16 13:02:09

I'd be surprised if this were the case as both controllers are being created by the object container, which will use a different DBContext for each one. I'd expect the dependencies to cascade as new instances. BUT some caching like this must be happening somewhere to result in the error I am getting

Tim Peel 2009-03-16 13:41:03

Seems MultipleActiveResultsSets=True doesn't quite fix things. This problem returned today. Then I noticed I had configured my IoC container to manage my context.

DaRKoN_ 2009-03-16 23:11:08

Answer 2

A:

One common mistake when using DI containers with ASP.NET MVC is that many DI containers default to a Singleton pattern. I don't know if that's the case here, but you should double check. ASP.NET MVC requires that the controller is created on every request because it has per-request state and context.

Haacked 2009-03-16 16:15:05

Thanks Phil but I'd say the controllers are getting created per request - I am just employing the MvcContrib controller factory wired up as per their examples. The ObjectFactory.GetInstance methods from StructureMap return new instances of the requested type. I'll keep digging!

Tim Peel 2009-03-16 17:45:42

Phil, thanks for making this point. I was under the impression (I'm sure I read it somewhere) that my DI container was setup to be per request by default and it turns out it's not.

DaRKoN_ 2009-03-16 21:50:13

@Haacked Structure Map defaults to a new one each time. Do you know if mvccontrib (or mvc) reuse instances?

eglasius 2009-03-17 02:37:40

Answer 3

+4 A:

I was talking to Jeremy Miller about this and you don't want to manage the lifetime of the db context with SM - let the repo instantiate as needed. This presents problems with how you will do object updating/persistence (if you're relying on a context staying alive for more than one request) but it's worth it to not rely on this for a web app.

I had to remove the db context management stuff from the storefront for a reason like this - I was getting memory leaks. I won't say it's SM's fault - but overall just let the repo open a new context.

Rob Conery 2009-03-16 17:42:47

Thanks Rob, that's very interesting. The DbContext management was based on the store front code. Is there any more info to explain this problem and how you identified it? I will check this is the solution tonight and feed back.

Tim Peel 2009-03-16 17:49:55

In my case, my repo's are newing up their own DBContext each time the repo is being created (eg manually in the constructor, not using 'using(){}' as per storefront code), My previous thoughts and Phils post point me to repo's that were being shared and not newly created.

DaRKoN_ 2009-03-16 21:52:19

@Rob - I made your fix and it looked to have sorted the problem but I saw it again last night. My repo now constructs its own DbContext at constructor level. I'm thinking of moving it to method level within a using statement.@DaRKoN - Have you progressed your problem?

Tim Peel 2009-03-20 10:16:03

Answer 4

A:

Are you completely sure nothing along in the object hierarchy is being Cached / or has a lifetime config? I have a prod app with a config just like this:

    ForRequestedType<SomeDataContext>().TheDefault.Is.ConstructedBy(
        () => new SomeDataContext(someConnString);

It isn't using asp.net MVC. Regarding the scoping issue, if you haven't set up anything, structure map will default to PerRequest (not asp.net request but structure map request, like each .GetInstance call) - http://structuremap.sourceforge.net/Scoping.htm. If you are positive on no configuration to affect it, then look at whether the mvc contrib or something else might be reusing instances.

Regarding the exception info posted. The error involves a combination of action results, action result filters, json serialization, custom methods, and also one linq2sql call failing because of an unexpected null. That's a combination of many different pieces, some of which I don't know. I would play safer and move the calculate stuff (that calls into linq2sql) being called when doing serialization to somewhere else where the json serialization/action results pieces aren't involved. This is just a wild guess, as I don't know how/when those pieces are called and what type of actions they have internally.

eglasius 2009-03-17 02:36:17

@Freddy - thanks. the problem has returned so I am back to finding a scoping issue. The object build that mvc is using calls GetInstance each time a controller is requested - how will this work with scoping? Will I ever get the same controller instance twice? I suspect this is happening.

Tim Peel 2009-03-20 10:13:11

@Tim as it has passed some time, please post the exceptions you are getting. Also consider running it using the mvc contrib source. I don't know much about the mvc contrib, I browse it a bit and I did wonder if subcontrollers might cause something like this (you didn't mentioned those thought).

eglasius 2009-03-20 19:14:11

@Tim when you debug it with the source, set a breakpoint on the context constructor, and run with it to see where/when it is being instantiated.

eglasius 2009-03-20 19:15:46

@Freddy - thanks again. Exceptions included in edited post. When I step through it, it never triggers the problem :( From the logging snippet, it shows different threads are involved yet there are still clashes on the dbcontext.

Tim Peel 2009-03-21 10:29:50

@Tim there are many pieces involved where the error occurs, I suggest moving the bits that call into linq2sql to a place in the code where there are less things involved. That's just a wild guess, as I don't know how many of those do internally (or how they are used in their respective context).

eglasius 2009-03-21 11:14:24

@Tim also, how do you tell the clashes are actually between different requests? Do you have something you can add to the log that identifies the request? so you know there is no internal weird automatic parallelization going on. Note: my suggestions are now more on isolating the problem.

eglasius 2009-03-21 11:17:13

ansaurus

tags:

views:

answers:

Strange behaviour with StructureMap / ASP.MVC / Visual Studio / LinqToSql

related questions