On Fri, 2009-06-19 at 09:38 +0200, Giacomo Tesio wrote: > But what if the DataContext MUST be longlived?
Then you're really screwed. Recall an earlier discussion this week about the lifetime semantics of IDbConnection. The IDbConnection could die for any reason, at any time, which is why most people use connection pools and keep the IDbConnection open for as short a period as possible. Alas, DataContext has no mechanism to obtain a new IDbConnection -- a specific IDbConnection instance is tied to the DataContext instance. If the IDbConnection is invalidated for any reason, the DataContext is FUBAR, and while normally you could create a new IDbConnection instance for your next request, that wouldn't be possible with DataContext. In short, you can't reliably use long-lived DataContext instances. > And what if the MappingSource comes from a stream (like > XmlMappingSource does)? I'm sure we could optimize this as well. As I mentioned elsewhere, there's a world of difference between reading an XML file into memory, vs. reading the XML file into memory and creating the entire object graph of Meta* types that mirror the XML. > Such a stream based mapping need to parse the stream as it comes, so > that lazyness could be problematic. There are different layers of lazyness. Consuming the XML wouldn't be lazy, but creating the wrapping Meta* objects could be. - 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 -~----------~----~----~----~------~----~------~--~---
