Implement synchronous execute without calling async implementation

[fsprojects]

Implement synchronous execute without calling async implementation

[dmitry-a-morozov]

I was considering different options to solve the issue and no one is completely satisfactory. This due to combination of different factors:

• Although TransactionScope is handy idea but it gets really tricky http://stackoverflow.com/questions/2884863/under-what-circumstances-is-an-sqlconnection-automatically-enlisted-in-an-ambien
• Of course the issue exists for both AsyncExecute and Execute. The reason I hesitated to implement sync execution as first class concept is because it will require to duplicate all the logic (due to type constrains). I prefer to avoid it if possible. Actually I see sync execution as convenience concept for reasons explained here http://channel9.msdn.com/Series/Three-Essential-Tips-for-Async/Async-Library-Methods-Shouldn-t-Lie and here
  #5 (comment)
• That said I think real-world application concerns should be address. I see 3 reasonable ways to solve the problem:
  • Implement transaction propagation logic similar to TransactionScopeAsyncFlowOption.Enabled on .NET 4. It should not be too hard but might get tricky. Also, it will fix only sync case. For AsyncExecute TransactionScopeAsyncFlowOption.Enabled still has to be used.
  • Add constructor overload that accept SqlConnection object. This connection must be open and enlisted into ambient transaction.
  • Add to AsyncExecute/Execute last optional parameter of type SqlTransaction.

@danielrbradley What do you think about these options?

[danielrbradley]

I guess the transaction are really an edge issue, so I don't think any of these solutions would actually be necessary.

While the project is still under heavy development I agree that simply providing the synchronous overload is sufficient as a placeholder for convenience, however, when the project heads towards a "1.0" status, as recommended in the channel 9 video, we would not want our synchronous method to lie, and we'd want to look at putting in this work to create a true synchronous method then.

In terms of those three options, if there was a wider requirement for transaction support, I'd personally lean towards the first option as it doesn't pollute the parameters, but if that is too tricky either of those two options would be equally workable.

[dsevastianov]

Transaction support has been added in Nuget release 1.1.28. Constructor now accepts SqlTransaction as input. This might not be ideal but that's the best we can do without complete duplication of all Async-related code.

use ts = TransactionScope
let conn = SqlConnection
conn.Open()
use tran = conn.BeginTransaction
let cmd = MyQuery(tran)
cmd.Execute(...)
tran.Commit()
ts.Complete()