I wonder are going to add APM (asynchronous programming model) support into ODP.NET ?
I mean implementing true asynchronous methods like OracleCommand.BeginExecuteReader/EndExecuteReader.
SqlClient has them for ages.
True async methods very improve scalability of server apps.
Asynchronous commands are not planned for the next ODP.NET release. I have not received too many requests for this feature, maybe since there are other ways to program asynchronously in .NET. If you have a business/technology case why you need use ODP.NET async commands (and why other asynch programming methods won't work well for you), send me an email
I understand that you don't get many requests for this feature. Async programming is still pretty uncommon and complex. But there is some significant efforts from Microsoft to make it much easier. TPL (Task Parallel Library) is an example.
As for "other ways to program asynchronously in .NET" I have to say I completly disagree. RDBMS is resource manager and no one except itseft can do true asynchronous proccessing. Surely we can use ThreadPool for spliting execution logic onto 2 threads. It's asynchronous programming for sure, but it's not real asynchronous processing bacause we have the same threads count as in synch case (and even a bit more overheads). (out program logic can continue execution but these's a thread in threadpool waiting for DB's response and it's blocked)
Why do we need true async exucution in resource managers?
Image a server application. Let's it has a WCF-server MyService with a method GetData:
public interface IMyService
public MyData GetData();
An implementation of this contract is creates OracleConenction, open it, create OracleCommand and executes it.
It's synchronous case.
Let out server app is under heavy load of concurrent users (300 for an example). And sql command which MyService is executing is pretty complex and takes OracleDB a couple of seconds to finish. What number of theads will out server app have? 300 at least. It's very very bad.
Yes, we can throttle requests into a queue, but then throughtput will be even less.
Now if we turn our WCF-service into asynchronous service with AsyncPatterns=true we'll get something like this:
public interface IMyService
public IAsyncResult BeginGetData(AsyncCallback callback, Object state);
public MyData EndGetData(IAsyncResult ar);
WCF infrastructure would call out BeginGetData with its callback, our service implementation would call OracleCommand.BeginExecuteReader (if it exists) and a thread would return to threadpool. It wouldn't blocked waiting DB's response anymore. No threads would blocked!
With such scenario and using SQL Server (SqlClient supports APM) we saw a number of threads in server app in async case is 10 times less that sync case!
i.e. instead of 300 threads we got 30 threads!
It's impossible to achieve with OracleDB+odp+.net.
I can't say it's a blocking issue but I'm sure it's significant disadvantage.
p.s. True async processing is based on async device IO operations. So it probably has nothing to do wit ODP.NET itself but with unmanaged OracleClient.
+1 I'd love to see that also. Async programming will shortly become common place with async/await native compiler support available for a while already. Support for true async I/O (when calling services/databases/...) will become mandatory in server solutions for scalability and efficiency reasons.