Are there plans to move optionally to full manual connection control and is it possible to do so already with a hack in 5.0?

I Regularly do applications that are high performance / high concurrent. The logic is not necessarily complex, but it is tedious to run into full "retry" mode. We talk of items such as queue control for a HPC system etc. - it is important that when asking for a "not assigned" job, no other query gets the same data. The logic normally looks "read, update, write". I don't want to move that to SP's "just because".

For a scenario like this, full connection control (also in regards to isolation levels) plus possibly even lock / lock ignore hints are critical. For example, I have a web portal that also shows the queue. I really don't need "committed only" there - I can totally live with (a) reading uncommitted and (b) even skipping rocked rows. This is informational info anyway only.

What I can not have though is having 100 agents pull the same row and "fighting out who gets it" (and then retry), and that is where we currently are going to.

Any work being done? I can see an ConnectionScope being done at v4 times by a third party (http://www.codeproject.com/Articles/71030/Connection-Scope-for-the-Entity-Framework) and that concept looked quite well... Sadly, I am unable to keep a connection open in v5 at all.

TransactionScope is NOT a solution - that forces a DTC involvement the moment the 2nd operation happens, and that has a COST.

@NetTecture EF6 provides additional control for connection handling. In particular, you can now create a DbContext with an already open connection--see http://entityframework.codeplex.com/workitem/45

Also, you can now explicitly tell EF to use a DbTransaction that you control--see design meeting notes here http://entityframework.codeplex.com/wikipage?title=Design%20Meeting%20Notes%20-%20January%2031%2c%202013 and here http://entityframework.codeplex.com/wikipage?title=Design%20Meeting%20Notes%20-%20February%207%2c%202013 for details.

Thanks,
Arthur

VERY good. This turns it from unusable to useful. I have regularly complex update / manipulation scenarios.

For example right now, I need, in one transaction:

• To call a stored procedure
• Then to submit changes - which inserts a ton of new objects
• To call another stored procedure.
  

Hard so far - good work.