multithreading problem

[Jeff]

Hey

..NET 2.0

I'm developing an application which will perform some webservice calls and I
believe having those calls in a separate thread may help the app run
smoother

No user are waiting for the result of these webservice calls, Each night
this code calls some webservices, which return a result I need to store in
the database (hence I mention "_db" in the context below).

So I'm trying to figure out how to implement this, and have come across a
few issues regarding this:

PROBLEM 1:
This app has an class variable called _db, it holds a reference to the
dataset. When the app is initialized this variable is initialized too.

I created a static method which I try to access this _db variable from, but
I get an compile error because I'm trying to access the _db variable from a
static method.

I believe it's possible to create a local version of _db in the static
method. But then there will exist 2 references to the dataset and might
(AFIAK) result where one main thread reads from the table while another
thread updates the table. (dbms is sql server 2005)

PROBLEM 2:
Do you recommend me using delegate and begininvoke etc.. or create a new
thread each time this will execute - > an thread which ends when the
webservice return and database is updated?

any suggestions?

 

[Peter Duniho]

[...]
PROBLEM 1:
This app has an class variable called _db, it holds a reference to the
dataset. When the app is initialized this variable is initialized too.

I created a static method which I try to access this _db variable from,
but
I get an compile error because I'm trying to access the _db variable
from a
static method.

I believe it's possible to create a local version of _db in the static
method. But then there will exist 2 references to the dataset and might
(AFIAK) result where one main thread reads from the table while another
thread updates the table. (dbms is sql server 2005)

If that's a risk, then you likely would have to perform synchronization on
any single instance of _db anyway.

The more general issue is: why are you writing a static method that needs
access to instance members of a class? This suggests that somewhere,
there's something broken about the overall design (hopefully something a
minor change can fix).

There are (at least) three different scenarios that might guide the design
of your class:

1) Common data shared among all clients of the class, with no chance
of ever needing to inherit the class

2) Common data shared among all clients of the class, but with some
chance that the class may benefit from serving as the base class for some
other new class

3) Data that is specific to each client of the class

Scenario #1 argues for a plain old static class, with everything being
static. #2 argues for a singleton, with a static accessor to retrieve a
single, shared instance of the class. #3 argues for the usual non-static,
non-singleton class.

You seem to be dealing with a non-static, non-singleton class, so
hopefully there's some reason you want to have multiple instances of the
class. But one way or the other, you need access to your "dataset" (is
this an actual DataSet class instance?). If you see a need to store it in
an instance of the class, then you'll obviously need to have that instance
to get at the variable.

The singleton approach solves this by ensuring there's only ever one
instance, one that all the clients use. Then it's a simple matter of
getting that instance when you need it.

If you really want multiple instances of the class, but only one DataSet
shared by all, it's simple enough to make that DataSet variable static.
Then it would be accessible by all, including any static methods. Note,
however, that doing it this way you would have to synchronize any write
operations with the DataSet (read operations are thread-safe, according to
MSDN).

Finally, it seems to me that you should be able to have multiple DataSet
instances, because SQL server itself is (or should be) multi-connection
safe. As long as each use of the DataSet represents a new connection to
the database, having multiple connections shouldn't hurt (other than
whatever cost there is for a connection), and without you having to do
anything special to synchronize the accesses.

But even in that latter case, it begs the question as to why you want to
access this thing that is normally something per-instance, but from a
static method. Hopefully somewhere in the above possibilities, you'll see
a design that is more appropriate than whatever you've got now that led
you down this dead-end road.

PROBLEM 2:
Do you recommend me using delegate and begininvoke etc.. or create a new
thread each time this will execute - > an thread which ends when the
webservice return and database is updated?

I probably wouldn't bother creating a new thread, as the existing thread
pool stuff should handle this sort of thing just fine. BeginInvoke()
called on a delegate instance uses the thread pool automatically, or you
can use BackgroundWorker, or you can queue a work item directly with the
ThreadPool class. Which works best for you would probably depend on your
specific needs. If it simplifies synchronization to have events
(progress, done) raised from the worker thread, but executed on the thread
that created the worker, then BackgroundWorker is a nice solution for
that. Otherwise, the other two alternatives would be fine (and IMHO not
terribly different from each other).

Pete

 

[Cor Ligthert[MVP]]

Jeff,

I seldom really become confused from messages, however you realised that.

What is your scenario.

1. Are you users using a solution that collects information from
webservices?
2. Do you have a webservice that gives information to your users.

In the first situation can multithreading be helpful as the Internet
connection from the users is faster then from the suppliers. You can however
not share your dataset because a dataset is only available at the clients
computer in that situation.

In the second situation multithreading does nothing, because the webservice
(webapplication) is from its nature self already multithreading. Static in a
webservice means that your application belongs then to all users so you have
to make a kind of registration in it to see which user is using it. To say
it easier: a horse behind the cart.

If your tables in the second situation in your database have primary keys
with automatic integers, then you are in trouble, if you use Guid's for that
then it is just simple inserting in the tables.

Cor


"

 

[William Stacey]

Is this "db" a Linq to sql classes context?
If so, there is no need to hold it. Just create when you need to do your
unit of work and dispose using the "using" pattern.