On Tue, 2009-06-16 at 05:34 -0700, greyman wrote: > I can tell you from experience though that no matter what MSDN says > there are at least some ADO.Net data providers that work a lot better > from a fault tolerance point of view if you create a new IDbConnection > object rather than opening a closed one.
So in your experience, long lived IDbConnection instances are bad. What is long lived -- seconds or minutes? I'll go out on a limb and assume that seconds is not long-lived. :-) That said, the guideline [0] seems to be that a DataContext should be created as a method local variable, not as a class field. Thus the DataContext lifetime should be fairly short (i.e. seconds, not minutes), removing most issues with reusing IDbConnection instances. For example, most [1] code doesn't provide an IDbConnection instance, but instead uses the connection string. This will BY NECESSITY result in the creation of a *new* IDbConnection instance every time a DataContext is created. (Using the connection string has added benefits such as allowing specification of the SQL vendor w/o using DbLinq extensions such as the DataContext(IDbConnection,IVendor) constructor.) In short, for apps following existing guidelines (short-lived DataContexts and connection strings), I don't think reusing the IDbConnection instance will cause any problems. For apps which do explicitly provide an IDbConnection, then the onus is on them to recreate the IDbConnection as appropriate, as DbLinq won't do so (nor should it be expected to do so, given the design). - Jon [0] I'd swear I saw a better guideline elsewhere on MSDN, but this is the best my Google-fu can currently find: http://social.msdn.microsoft.com/Forums/en-US/linqprojectgeneral/thread/ea6fe19c-cd21-40d1-b005-750af6632bfe [1] "most" is, of course, pulled OOMA, but this is true for most example code I've seen on MSDN. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
