On Sun, 2009-06-14 at 05:05 -0700, greyman wrote: > On Jun 14, 9:26 am, "Andrus Moor" <[email protected]> wrote: > > Currently dblinq seems to work in this way: new IDbConnection() reads > > connection from static thread-safe ado .net pool (if ado provider implements > > pooling). > > IDbConnection.Dispose() issued by connection creator (dblinq or user who > > passes connection) returns connection to pool. > > > > So I don'nt undrestand what to do? > > At the moment there looks like each DbLinq DataContext will only ever > create a single IDbConnection (which represents the physical > connection to the database) object. The creation is done in > DatabaseContext.Connect. The single connection object is then passed > to other DbLinq classes to consume. In DatabaseConnection.Dispose the > connection is closed but not disposed of, it would be a problem if it > was disposed of since it is still reference and required by the other > consuming classes. > > The correct way to use ADO.Net connection pooling is rather than > keeping a reference to a single connection object and passing it > around the is to create and open a new connection everytime and let > the ADO.Net provider connection pooling take care of reusing > connections. Once the connection is finished with it should be closed > and de-referenced or disposed of. It's something that looks easy to > fix in DbLinq which is good news.
This is a known issue. (Known to me as of two days ago. ;-) The larger problem is that the current mechanism interacts *horribly* with transactions (i.e. it doesn't work with DataContext.Transaction AT ALL). The result is that I've had to disable several unit tests which require use of Transactions (see my prior message about "unit tests which altered the database"; I'm using Transactions in some tests to prevent the changes from being persisted). (The problem is that DataContext.Transaction is currently ignored, and my feeble attempts so far at making DataContext.SubmitChanges() support DataContext.Transaction results in "transactions within transactions are not supported" errors, because in various places DatabaseContext is being used when executing the SQL commands, and may implicitly create a new context. This is obviously BAD.) I think the entire use of DbConnection/etc. needs to be reworked (possibly by removing DatabaseContext?), but I'm not sure when I'll get to it. :-/ - Jon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
