IO-APM Implement in NHibernate
Description
Environment
depends on
is duplicated by
Activity
Alex Zaytsev August 30, 2017 at 10:57 PM
Closing in favor of true async version (). There is no intention to support BeginXXX/EndXXX patterns.
Boštjan Markežič October 16, 2016 at 12:52 AM
I agree with you that the above difference is not significant so it seems that the async parameter approach is more convenient.
The only thing that should be considered using the asnyc parameter is deadlocking. Here is an example:
Even if the return type is a Task the developed will need to check if he can perform an async call or not by using the async parameter.
This is a little missleading but with proper documentation this should not be a problem.
Onur Gumus October 15, 2016 at 3:21 PMEdited
Yes, these results make better sense to me. And if the DB happens to be on a remote computer, the difference will even be smaller. I followed your commits and saw you have spent some significant effort with your async generator branch. I applaud it. But with these results, I would say it's not worth the trouble.
Boštjan Markežič October 15, 2016 at 3:13 PM
I am running SQL Server 2012 on the same machine that the test was ran. I removed the Deletion and the execution time is now almost the same on both versions, very interesting. Here is the new Test:
With the old version:
1 -> 00:00:00.9584109
100 -> 00:00:05.7978922
500 -> 00:00:18.2312835
With the new version:
1 -> 00:00:00.8234113
100 -> 00:00:05.3817286
500 -> 00:00:17.9973287
Onur Gumus October 15, 2016 at 2:16 PMEdited
Also this could should be better out of your benchmarking , before the stopwatch starts. Since first run test will be faster then the later ones.
foreach (var order in session.Query<Order>())
{
session.Delete(order);
}
As such you might open a cleaning transaction before .
Details
Assignee
Alex ZaytsevAlex ZaytsevReporter
李永京李永京Labels
Components
Affects versions
Priority
MajorWho's Looking?
Open Who's Looking?
Details
Details
Assignee
Alex ZaytsevReporter
李永京Labels
Components
Affects versions
Priority
Major
many people hope a IO APM(http://msdn.microsoft.com/en-us/magazine/cc163467.aspx) Implement in NHibernate. We use SQL Server 2005 and we are building a client software. Now we have to execute SQL in UI Thread because of Session is not thread safe. It will display "No Respongding" in our application when a great amount of data to Submit to DB.
We know .net framework support IO-APM from version 2.0. The class SQLCommand has a method called "BeginExecuteNonQuery" and "EndExecuteNonQuery", It implements standard APM pattern. So We can use it to send async request to SQL Server. It return immediatly. When Database finished, It will callback and send the data We need. IO APM do not need another thread, just use hardware IOCP. So it will save computer resource and cost less CPU time. Some .net FCL implement APM, such as Stream.BeginRead, Delegate.BeginInvoke, SQLCommand.BeginExecuteNonQuery. As you know, .NET 4.0 enhance parallel task to use multicore support. We think if NHibernate implement APM will take full advantage of hardware support.
We have a glance at NHibernate source, We find it use the interface "IDBCommand.ExecuteNonQuery". The APM support only occurs in SQLCommand. So can you add a callback method like "IAsyncResult BeginExecuteNonQuery(AsyncCallback callback, object stateObject)? Although it only support SQL Server, it can decrease UI responding time and less cost of CPU resource.
In our opinion, If this function occurs in the next version, everyone who use NHibernate will reap the benefits of APM async pattern.
So could you help us to let NHibernate support APM? If you have any idea, please contact with us freely.