On Fri, 28 Dec 2007 01:34:59 -0800, Jeff <do***@spam.mew rote:
[...]
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 BackgroundWorke r, 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 BackgroundWorke r is a nice solution for
that. Otherwise, the other two alternatives would be fine (and IMHO not
terribly different from each other).
Pete
