Performance when using with WCF

When I use the entities within a WCF muti-tier service, the performance is terrible. I am guessing that it is trying to search for the WCF transaction I have not specified any WCF transactions, and am using basic http binding.

The performance is so bad that the WCF service is timeouting even when i set the timeout to about 1 min. Has anyone out there used entities in a WCF service

Visual Studio 200813

It depends on what you mean by using Entities within a WCF service. I would say that even if technically possible, you should never attempt to return a "live" entity as a return value from a WCF service (or a Remoting call or any other cross-AppDomain bridge).

What I have done in the past is use completely serializable structs that I return from WCF calls where the WCF service itself invokes the entity framework, does its query, gets an entity or list of entities, then turns it into something that is marshallable by value, not reference.

I think what we should see here is some way to take a "live" entity and disconnect it from the underlying model so that there are no traps for property change events and no attempt at remote identity management, etc - that would enable you to pass disconnected entities around across AppDomain barriers. I don't know if entity classes have some functionality like this built-in that I'm not aware of

In short, every attempt I have made to use entities in cross-AppDomain scenarios has caused me nothing but trouble and I have had to do some small workarounds to leave the entities within a single AppDomain and use lighter-weight constructs to transmit results out.

You are right, I am not attempting to return an entity. It is not possible because in WCF Services we can only pass or return object by value not by remote reference.

I am doing what u are saying, but when I use entities in a service the performance takes a hit, I just want to know if others are also seeing this behaviour and what is the work around

We're actively working on some incremental changes to the entity framework to facilitate these kinds of scenarios. There's no way we're going to get as far in Orcas as we would like, but we are definitely making some progress both to add capabilities to the framework (like attaching a graph of entities to the context directly into an unmodified state rather than just supporting add, including some serialization attributes to make things a bit quicker/easier to serialize with WCF, etc.) and to explore (and eventually document) some effective patterns for creating web services using entities.

This is definitely part of our goals for Orcas (just not quite all complete yet).

I think what we should see here is some way to take a "live" entity and disconnect it from the underlying model so that there are no traps for property change events and no attempt at remote identity management, etc - that would enable you to pass disconnected entities around across AppDomain barriers. I don't know if entity classes have some functionality like this built-in that I'm not aware of

For a single entitiy this is relatively easy to do: find the CacheEntry for the entity (renamed to StateEntry in more recent versions which may or may not be in the build you are working with), call Delete on it, and then call AcceptChanges. This will cause it to be removed from the cache but that change to be marked as accepted so that a later call to SaveChanges won't try to delete the entry from the database.

That said, I'm not sure the scenario where you are concerned about the need to unhook the entity from change tracking and things like that. In most of the scenarios I've looked at, once the entity is remoted the object on the other side is going to be unhooked already (because it's a copy reconstituted from what ever remoting format). Could you give me more info about the scenario you are having trouble with