On Sun, 2009-06-14 at 16:51 -0700, greyman wrote: > What about leaving a slight modification DatabaseContext where the > Connection property is removed and replaced with a method > GetConnection. Instead of caching the IDbConnection object as is > currently done everytime a parent class wanted to use a database > connection it would call the GetConnection method which would create > and open a new one. For this to work properly and not chew up every > database connection in the pool every call to GetConnection would have > to be wrapped in a using block so that the connection was returned to > the pool after use. The using block wraps do seem to be already used > in a lot of places but not everywhere.
I'm still not seeing the benefit here. DataContext.Connection already exposes the IDbConnection instance to use, and DataContext appears to be accessible from nearly everywhere of consequence. DatabaseConnection does have one benefit: it can centralize the logic for when to close the connection, as required in http://msdn.microsoft.com/en-us/library/bb292288.aspx: A DataContext opens and closes a database connection as needed if you provide a closed connection or a connection string. In general, you should never have to call Dispose on a DataContext. If you provide an open connection, the DataContext will not close it. Therefore, do not instantiate a DataContext with an open connection unless you have a good reason to do this. In a System.Transactions transaction, a DataContext will not open or close a connection to avoid promotion. So DatabaseConnection handles the implicit opening and closing of the IDbConnection when it's needed. That seems fairly useful to me. (Though it should be enhanced to check for presence of a transaction and not open if a transaction is in process, though this might not be necessary -- shouldn't the connection already be open for it to be part of a transaction?) DatabaseContext, on the other hand, has methods that aren't used used anywhere (as far as VS is concerned) such as DatabaseContext.Connect(), or DatabaseContext(DbProviderFactory) (why should we care about DbProviderFactory?). It's apparently "utility for the sake of utility" rather than necessity, and what's necessary is *working* Transaction support (e.g. get Transactions.TransactionRollbackDelete() and Insert_Update_Delete.LinqToSqlInsert06() working), along with supporting the documented DataContext IDbConnection semantics (e.g. open the connection for as short a period as possible, leave open if the connection was originally open, wrap DataContext.SubmitChanges() within a transaction UNLESS DataContext.Transaction isn't null, in which case we reuse the existing transaction, etc.). My suspicion is that just getting transactions working properly will result in either simplifying or removing many of these types, so I would suggest trying that first. :-) > I don't mind having a crack at implementing this but would like to get > an indication that the design at least sounds ok. Otherwise there > could be an obvious critical thing I'm missing. I don't see how your approach of using GetConnection() would work, actually. DbLinq cannot require creation of new instances, as the IDbConnection instance may be provided to the constructor, and IDbConnection isn't ICloneable. How could we reliably create new connections? The only solution I see, baring glaring bits of idiocy on my part, is to open and close the IDbConnection on-demand whenever we perform a SQL command, with the proviso that we don't close the connection if it was already open when the DataContext was created. DatabaseConnection should help with this logic. Thanks, - 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 -~----------~----~----~----~------~----~------~--~---
