On Jun 16, 5:51 am, Jonathan Pryor <[email protected]> wrote: > > 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.
I see your points. Some extra conditions I have come across are: 1. DataContext is relying on a single physical database connection and has no mechanisms to cope if that connection enters an inconsistent state and cannot be read to or written from, 2. The physical database connection is closed by the server or by a network condition. I guess the way these condiions are to be handled is that the DataContext object will throw an exception and the consuming class will need to create a new DataContext object and have it create a new IDbConnection or pass a new IDbConnection to it. The key there is that DataContext should not attempt to open any IDbConnection more than once. If there is a need to re-open a connection is probably means something bad has happened and a new connection should be acquired from the pool by creating a new IDbConnection object. 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 -~----------~----~----~----~------~----~------~--~---
