On Jun 15, 12:23 am, Jonathan Pryor <[email protected]> wrote:
> This is a known issue.  (Known to me as of two days ago. ;-)
>
> The larger problem is that the current mechanism interacts *horribly*
> with transactions (i.e. it doesn't work with DataContext.Transaction AT
> ALL).  The result is that I've had to disable several unit tests which
> require use of Transactions (see my prior message about "unit tests
> which altered the database"; I'm using Transactions in some tests to
> prevent the changes from being persisted).
>
> (The problem is that DataContext.Transaction is currently ignored, and
> my feeble attempts so far at making DataContext.SubmitChanges() support
> DataContext.Transaction results in "transactions within transactions are
> not supported" errors, because in various places DatabaseContext is
> being used when executing the SQL commands, and may implicitly create a
> new context.  This is obviously BAD.)
>
> I think the entire use of DbConnection/etc. needs to be reworked
> (possibly by removing DatabaseContext?), but I'm not sure when I'll get
> to it. :-/

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 think the redundant class is DatabaseConnection. If an approach like
the one above is used it would no longer be needed.

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.

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
-~----------~----~----~----~------~----~------~--~---

Reply via email to