Connection Instance Members are not thread safe question.

I wouldn't really expect a connection to be thread-safe.
Personally I'd let the data-access code worry about their own
connections from a connection-string (or named key), and let the
ADO.Net connection pooling worry about the rest (making sure I use
"using" etc). As long as each connection / command is local to a thread
(and/or method block) then thread safety isn't an issue... however, you
must be aware of transactional issues, especially if you are directly
competing for data; you can either block or deadlock yourself very
easily.

Was this the question, or am I off to one side?

Marc

I think Marc pretty much hit on the gist of this. The key concept here is
"what kind of connection" are we talking about. If it is an SqlClient
SqlConnection, you should be more concerned with whether it will be correctly
Connection Pooled rather than worrying about whether it is threadsafe or that
you might need copy constructors.

post some sample code, and we'll try to help nail down the basics for you.
Peter
--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"Karen Hill" wrote:

I have a winform in .NET 2.0 that uses will require the use of a
backgroundWorker thread due to the long processing time of one Command
.. I have a data provider whose Connection class is not thread safe. I
would like to know what the _best_ way to implement this is. Do I
create a copy constructor for the Connection class and create a new
instance for the Connection that will be used in the threaded function?
regards,
karen