When I instance my "Entities" object in Entity Framework, and make a couple of queries using that Entities object, what happens to connections?
Does it open a connection when I instance the object, and close it when I dispose of it?
Or does it open and close a connection for each single query I execute?
In either case, is it possible to change it so that it does the other thing?
Basically it opens when a request is called and closes once the results have been disposed or consumed. You can manually open/close or use the same connection using the object context...
This article has a more complete explanation -
http://msdn.microsoft.com/en-us/library/bb738582.aspx (archive.org)
Here is the How To on using an entity Connection -
http://msdn.microsoft.com/en-us/library/bb738461.aspx (archive.org)
The behaviour changed somewhat in EF6, allowing you to pass in open connections or to open the EF connection yourself later. Check out https://msdn.microsoft.com/en-us/library/dn456849(v=vs.113).aspx
Related
I'm using grails 4 to develop my backend, and I want to control how connections to my MongoDb is logged. Right now, nothing is logged (at least not unless the connection fails). There seems to be a lot going on under the hood, and the whole process of connecting to my database is very much hidden. It seems like the main bean that takes care of this is called mongoDatastore, but is there an easy way to, for example, register a listener for connection events on this bean? Or do I have to extend MongoDatastore and register my own bean?
I also had an idea of using the applicationContext to fetch the bean, and from there somehow register an event listener, but I don't know when or where in the initialization phase I would to that.
All MongoDB 4.4-compatible drivers publish CMAP events that the application can subscribe to. These tell you when individual connections are made and closed as well as pool behavior.
In highload legacy application I've found tons of code which just creates new DBContext, then makes request and doesn't dispose the DBContext at all.
Monitoring shows 200 connections opened all the time and disposing all DBContext doesn't resolve this issue.
Connection pooling is by default. Database: MariaDB.
If it's important, this is servicestack
Could you please share ideas on how to resolve this: decrease the level of opened connection so that the number of opened connection would correlate with the REAL number of connection from DBContext.
Also I've looked through the following links:
DbContext disposing?
EF DBContext dispose not closing the connection
Not Using Dispose or Using() in Entity Framework
Should i use Pooling=False in Entity Framework Connection String?
Entity Framework and Connection Pooling
Is there a way to execute the DbContext.SaveChanges() without invoke its internal auto transaction handling?
I'm working to handle the transaction (DbTransaction) myself, but when I invoking it's Commit, I getting error "SqlConnection does not support parallel transactions"
I believe this is due to SaveChanges is doing its own internal transaction work, which I want to suppress it.
.NET 4.5, EntityFramework.dll ver 5.
googling shows few approaches, but the code are not compatible.
Some showing SaveChanges can accept a Boolean, which it is not in this ver. and then invoking AcceptAllChanges() which method also not exist.
While some is using System.Transaction.TransactionScope, but its different with this System.Data.Common.DbTransaction.
after many PITA efforts digging over the EF thing. the only way I found out to have proper transaction control over it is best to use ObjectContext, instead of DbContext.
http://sqlanywhere-forum.sap.com/questions/11320/entity-framework-savechanges-closes-connection
this hinted the ObjectContext
DbContext codebase is genereated if your EDMX code generation strategy is set to None.
link: Is ObjectContext deprecated in .NET 4.5?
by changing it to Default, you will get ObjectContext code base gen.
the diff of them so far of what I found out, using DbContext, whenever you invoke its SaveChanges(), it will AUTO close the underneath connection, and your next db task will have a new connection, which basically break the transaction control of what I seek.
you need to run the whole db tasks without the conx being close or recreate within the transaction.
by using ObjectContext, SaveChanges() will not auto close the connection if I setup the transaction and connection codes properly before it.
After using EFProfiler (absolutely fantastic tool BTW!) for profiling a few of our Entity Framework applications, it seems that, in most cases, all of the Object Contexts are not closed.
For example, after running it locally, EF Profiler told me that there were 326 Object Context's opened, yet only 1 was closed?
So my question is, should I worry about this? Or is it self-contained within Entity Framework?
If you're not using an IoC container is there anyway you can close the ObjectContexts manually after each request, for example in the End Request of your Global.asax, thereby simulating a "per request" lifestyle for your contexts?
ObjectContexts will be disposed eventually if your application is not holding onto them explicitly, but in general, you should try to dispose them deterministically as soon as possible after you are done with them. In most cases, they will hold onto database connections until they are disposed. In my current web application, we use an IoC container (Autofac) to ensure that any ObjectContext opened during a request is disposed at the end of the request, and does not have to wait for garbage collection.
I suggest you do worry about it and try to fix the issue as Object Contexts are pretty "bulky". If you have too many of them your application may eventually end up using more memory than it needs to and IIS will be restarting your application more frequently then...
If anyone has any experience in this framework: https://github.com/eczarny/xmlrpc/, it would be best, but I will try to fill in where I can.
There's a connection manager class, that stores each connection in a hash table that uses a UUID as the key. The manager has a method that you can spawn a new connection with a request object. Here's the problem:
I can get the connection object, but I can't find a way to send another method request through the same connection. The only thing I saw was a class method that is public, otherwise I can't figure out how to send another request through the same connection. Do I need to keep making new connections in order to do this?
Here's the connection class: https://github.com/eczarny/xmlrpc/blob/master/XMLRPCConnection.h
Here's the manager class: https://github.com/eczarny/xmlrpc/blob/master/XMLRPCConnectionManager.h
Turns out there is no way to get this connection again. It's just a one-use connection. I asked the author to confirm.
I've never used this Framework, but upon looking at it briefly I came up with this. Theres a method,
- (XMLRPCConnection *)connectionForIdentifier: (NSString *)identifier;
If you can store reference to the identifier for the request you make the first time, then you can retrieve the same Connection with provided identifer, and not create a new one.