Create new instance of Database all the time, or keep around?
With the access to the underlying data store being abstracted and relatively hidden from us, I find myself wondering how to manage connection pooling and scalability.
I have a static utility class that provides all the methods that generate queries. At the moment, it creates a singleton instance of the Database class (e.g. MyDatabase() , the one created by Sqlmetal) (this is for LINQ to SQL, not EF).
Should I be creating and disposing of the database instance within each data request method, or should I be trying to maintain the reference to the static instance of the db? My gut instinct tells me to do something like this :
public static List<MyData> GetSomething(params)
{
using (Database db = new Database())
{
var x = from ....
return x.ToList();
}
}
Is this the right model, or should "db" be a static member parameter on the utility class?
I am experiencing pretty horrible performance right now when multiple users are hitting the system, and I'm thinking its because I'm using a static member for the database instead of a transient local variable.
Hi Kevin,
We'll do caching/pooling as appropriate internally in the stack, so the pattern that I would recommend is that you just "new" a new instance of the object-context every time. As for the definition of "every time", every method may be too much, I typically do this per "activity" or "request"; for example, use and discard an instance when handling a asp.net request, or a single web-service call, etc.
WinForms and other forms of stateful applications are different, because you want to preserve state between interactions so you know which objects you changed and stuff like that. In those cases you may want to keep the object-context around for longer periods of time.
NOTE: in the CTP we didn't put the caching/pooling infrastructure in place, which is why creating and opening a MapConnection is slow.
Pablo Castro
ADO.NET Technical Lead
Microsoft Corporation
So then rather than create a new instance of the Db model every time I invoke a method, I should probably create an instance of the utility class for every ASP.NET page request probably in the Page_Load, and have the utility class create the instance of the Db model in the constructor.
I think this will give me a "per activity" or "per request" methodology and maps well to my eventual upgrade from ASP.NET to WCF and services.
For a web application you'd typically new an
ObjectContect per use case scenario. In a windows application the
ObjectContect should be available for as long as the application runs, so new'ing it in the Main method and making it available in the top-level API of your program is sufficient.
Actually, probably not, because query resolution is always performed in the server (check
Danny's post) , so the 'cache' in ObjectContext is not actually a 'cache' in the sense of avoiding database roundtrips.
Regards,
Andres
The materializer, in turn, takes that DataReader and works with the context to find and return already existing object instances whereever possible and to create new object instances (and cache a reference to them) when necessary. By default, if the context already has an instance of a particular entity (as determined by comparing EntityKeys), that instance is returned by the materializer without making any changes to it.
Still, in the middle of a use case you want to keep the ObjectContext around instead of flushing incremental changes.
If I want to build a multi tier app, which is probably what want for Windows Forms apps, then I shouldn't use ObjectContext at all.
The EF is a Data Access technology and it shouldn't be used outside the middle tier...
Andres Aguiar wrote: