On Jun 17, 3:47 am, Jonathan Pryor <[email protected]> wrote:
> 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).
I'd agree with you again that if DataContexts are short lived the
benefits of handling its IDbConnection suffering a failure are small.
I first raised this thread before I was aware DataContexts were
supposed to be used for single units of work and I had by DataContext
with it's single IDbConnection trying to survive for my application's
whole lifetime.
I would still argue that it would be better to create and destory
IDbConnection objects in DbLinq's DataConnection class rather than
opening and closing an existing one, excepting where the IDbConnection
was provided to DataContext during instantiation. Yes the MSDN
documentation seems to make a point of saying IDbConnection should be
open and closed as needed within the DataContext lifetime but I wonder
if that statement was written with connection pooling in mind.
The thing I find confusing and what set me down the wrong path with
the usage pattern I employed for DataContext was that it looks like it
should be an application lifetime type object. It's arguable the
identity management and query caching in DbLinq won't be of much
benefit if the DataContext is only used for single units of work.
Regards,
Aaron
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
