Multithreaded access with TableAdapters

[Guest]

We have an app under development processing data from com port events. There
can be multiple com ports all sending data back to this one method on one
instance of a class “ldâ€. This method gets a db object associated
speciffically with THAT com port. The db objects wrap a datatable and a
tableadapter.
So if we have COM1, and COM3 in use we might have something like this

ld -> retrieves -> dataAdapterObjCOM1
dataAdapterObjCOM3

If I am running with only one com port all works fine. With more than one I
get many errors in the Designer class for the db stuff. All the db objects
are separate instance of objects specifically associated with that com port.
So no two threads should be trying to access the same db wrapper objects at
the same time.

The errors include:
The connection was not closed. The connection's current state is connecting.
When trying to insert with the adapater.
Note: I am testing for this connection state right before the insert line
and sometimes it will see it sometimes it won’t. I know doc says its for
future use but I am getting it now.
Object reference not set to an instance of an object. on DataTable NewRow()

I unplug the extra comport and everything works fine again.

Any suggestions?

 

[Miha Markic [MVP C#]]

Hi there,

DataAdapter, DataTable etc. are not thread safe.
Plus, if your DataTable is bound to an UI control then you can modify its
data only from within UI thread.
Plus, you have to make sure that you don't use same connection instance when
two threads require it.

 

[Guest]

That is what confuses me. Since each thread has its own instance of a
table&tableadapter wrapper object I shouldn't technically be doing
multithreaded access, right? At least not multithreaded in the sense of two
threads accessing the same instance of a tableadapter. note- It is not UI
bound.

Can anyone point me to some examples on managing connections in a
multithreaded situation? Right now my connection is defined in the
app.config, and every table adapter refers to that connection string. Someone
said each process manages its own pool yet apparently this setup is
unacceptable for multithreaded db access.

thanks