APM support in ODP.NET ever?

Alex,
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:
[ServiceContract]
public interface IMyService
{
[OperationContract]
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:
[ServiceContract]
public interface IMyService
{
[OperationContract(AsyncPatterns=true)]
public IAsyncResult BeginGetData(AsyncCallback callback, Object state);
[OperationContract]
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.


Some resources:
- http://blogs.msdn.com/wenlong/archive/2009/02/09/scale-wcf-application-better-with-asynchronous-programming.aspx
- http://msdn.microsoft.com/en-us/magazine/cc163415.aspx