Asynchronous dataset reading

  • Thread starter Thread starter Valerie Hough
  • Start date Start date
V

Valerie Hough

Hi,
I am debugging an application which uses C# with .NET v1.1. It attempts to
implement asynchronous dataset retrieval by using separate threads and
synchronizing them with the UI form. Recently the application is having some
problems whereby it is crashing with a "General Network Error" and a call
stack that looks approximately like this:

System.Data.SqlClient.SqlDataReader.TdsParser.ThrowExceptionAndWarning()
System.Data.SqlClient.SqlDataReader.TdsParser.ReadNetLib(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ReadBuffer(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ReadByteArray(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ReadEncodingChar(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ReadValue(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ProcessRow(...)
System.Data.SqlClient.SqlDataReader.PrepareRecord(int32)
System.Data.SqlClient.SqlDataReader.GetValues(Object [] values)
AsynchronousReadDataThread()

Notes:
- In the form application, Thread.Join() is used if the dataset read is not
complete.
- There might be 10-20 threads reading at any given point in time.
- It is a hit and miss type of problem that only seems to occur with heavy
usage across several CPUs.

Does anyone know what the cause of this might be?
Are these read threads safe if they happen to be executing views that might
join some of the same tables as one another?
Assuming that the asynchronous reading is necessary, is this approach
conceptually sound?
I see that .NET 2.0 is just released with support for this sort of thing
built in. Do I need VS 2005 to incorporate it into apps?

Thanks in advance for any help.
Valerie Hough
 
SqlDataReader is not designed for multi-threaded access. You cannot read
from the same SqlDataReader object through multiple threads without
serializing the access to this object among the threads.

Thanx
Lale Divringi

DISCLAIMER: This posting is provided "AS IS" with no warranties, and confers
no rights.
 
Thank you for your reply. Each thread that is created creates a new
SqlConnection object, a new SqlCommand object, and then does
SqlCommand.ExecuteReader(). I'm not sure if this is the 'same' SqlDataReader
or not. Please let me know, and, if it is, could you possibly suggest any
article that would describe how to serialize the access among threads.
Also, does it matter whether my thread is declared as static or not, and
whether it uses the SingleThreaded Apartment model or the MultiThreaded one?
Thank you in advance for your help.

Lale Divringi said:
SqlDataReader is not designed for multi-threaded access. You cannot read
from the same SqlDataReader object through multiple threads without
serializing the access to this object among the threads.

Thanx
Lale Divringi

DISCLAIMER: This posting is provided "AS IS" with no warranties, and
confers no rights.

Valerie Hough said:
Hi,
I am debugging an application which uses C# with .NET v1.1. It attempts
to implement asynchronous dataset retrieval by using separate threads and
synchronizing them with the UI form. Recently the application is having
some problems whereby it is crashing with a "General Network Error" and a
call stack that looks approximately like this:

System.Data.SqlClient.SqlDataReader.TdsParser.ThrowExceptionAndWarning()
System.Data.SqlClient.SqlDataReader.TdsParser.ReadNetLib(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ReadBuffer(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ReadByteArray(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ReadEncodingChar(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ReadValue(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ProcessRow(...)
System.Data.SqlClient.SqlDataReader.PrepareRecord(int32)
System.Data.SqlClient.SqlDataReader.GetValues(Object [] values)
AsynchronousReadDataThread()

Notes:
- In the form application, Thread.Join() is used if the dataset read is
not complete.
- There might be 10-20 threads reading at any given point in time.
- It is a hit and miss type of problem that only seems to occur with
heavy usage across several CPUs.

Does anyone know what the cause of this might be?
Are these read threads safe if they happen to be executing views that
might join some of the same tables as one another?
Assuming that the asynchronous reading is necessary, is this approach
conceptually sound?
I see that .NET 2.0 is just released with support for this sort of thing
built in. Do I need VS 2005 to incorporate it into apps?

Thanks in advance for any help.
Valerie Hough
 
Yes, 2.0 has "new and improved" async handling for the query-portion of the
query execution. The fetch portion is still up to you to handle. Can this be
done reliably in 1.1? I've done it... but reliability or scalability is
harder. If you over-stress the server or the client system with too many
operations, you can also generate errors that would not ordinarily occur.
Each connection can support one (and only one) DataReader at a time. If you
enable MARS you can execute more but I would investigate this thoroughly
first (I don't recommend MARS). These "general network" errors can occur if
the networking layers get disconnected or confused. They're also caused by
hardware disruptions.

hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

Valerie Hough said:
Thank you for your reply. Each thread that is created creates a new
SqlConnection object, a new SqlCommand object, and then does
SqlCommand.ExecuteReader(). I'm not sure if this is the 'same'
SqlDataReader or not. Please let me know, and, if it is, could you
possibly suggest any article that would describe how to serialize the
access among threads.
Also, does it matter whether my thread is declared as static or not, and
whether it uses the SingleThreaded Apartment model or the MultiThreaded
one?
Thank you in advance for your help.

Lale Divringi said:
SqlDataReader is not designed for multi-threaded access. You cannot read
from the same SqlDataReader object through multiple threads without
serializing the access to this object among the threads.

Thanx
Lale Divringi

DISCLAIMER: This posting is provided "AS IS" with no warranties, and
confers no rights.

Valerie Hough said:
Hi,
I am debugging an application which uses C# with .NET v1.1. It attempts
to implement asynchronous dataset retrieval by using separate threads
and synchronizing them with the UI form. Recently the application is
having some problems whereby it is crashing with a "General Network
Error" and a call stack that looks approximately like this:

System.Data.SqlClient.SqlDataReader.TdsParser.ThrowExceptionAndWarning()
System.Data.SqlClient.SqlDataReader.TdsParser.ReadNetLib(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ReadBuffer(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ReadByteArray(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ReadEncodingChar(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ReadValue(...)
System.Data.SqlClient.SqlDataReader.TdsParser.ProcessRow(...)
System.Data.SqlClient.SqlDataReader.PrepareRecord(int32)
System.Data.SqlClient.SqlDataReader.GetValues(Object [] values)
AsynchronousReadDataThread()

Notes:
- In the form application, Thread.Join() is used if the dataset read is
not complete.
- There might be 10-20 threads reading at any given point in time.
- It is a hit and miss type of problem that only seems to occur with
heavy usage across several CPUs.

Does anyone know what the cause of this might be?
Are these read threads safe if they happen to be executing views that
might join some of the same tables as one another?
Assuming that the asynchronous reading is necessary, is this approach
conceptually sound?
I see that .NET 2.0 is just released with support for this sort of thing
built in. Do I need VS 2005 to incorporate it into apps?

Thanks in advance for any help.
Valerie Hough
 
Back
Top