Question on use of Static Methods

[Joe Fallon]

In another post Kevin Spencer stated: "one should be careful of using static
fields, properties, and methods, by understanding what the implications of
such are (e.g. locking static variables when changing because they are not
thread-safe)."

Can someone please elaborate on the pros and cons of using static methods?
(In VB they are called Shared methods.) The MS DAAB uses Shared methods.
This means that all Data Access calls go through this block of code without
instantiating an instance. I assumed that this would be a highly scalable
solution. Is this assumption correct? Or are there drawbacks to using shared
methods that reduce the scalability? Do multiple users ever "step on each
other"? For example, can UserA end up with UserB's Datareader?

Appreciate any advice.
--
Joe Fallon

[John Saunders]

"Joe Fallon" <jf******@nospa mtwcny.rr.com> wrote in message
news:u3******** *****@TK2MSFTNG P10.phx.gbl...

In another post Kevin Spencer stated: "one should be careful of using static fields, properties, and methods, by understanding what the implications of
such are (e.g. locking static variables when changing because they are not
thread-safe)."

Can someone please elaborate on the pros and cons of using static methods?
(In VB they are called Shared methods.) The MS DAAB uses Shared methods.
This means that all Data Access calls go through this block of code without instantiating an instance. I assumed that this would be a highly scalable
solution. Is this assumption correct? Or are there drawbacks to using shared methods that reduce the scalability? Do multiple users ever "step on each
other"? For example, can UserA end up with UserB's Datareader?

Shared fields or properties are shared by all users. That's the big problem.

I don't know of a problem with accessing Shared methods which do not refer
to Shared data.
--
John Saunders
johnwsaundersii i at hotmail

[Rick Strahl [MVP]]

Generally static methods should never be a problem. Statics are nice
precisely because you don't need and instance ref first, although I suspect
that the overhead of creating an instance would be minimal in the first
place. More than anything it's about the convenience of having those methods
available directly without setting up an instance. If your methods don't
require class level data and they're self contained they're good canidates
for static methods.

it's static data you have to be potentially aware of for potential
multi-threading lock issues as any data that is static is shared by the
entire ASP.Net application and its AppDomain. I use static data quite a bit
in my apps for storing configuration data and a number of one time loaded
references to reused data of all sorts. If data is read only or only updated
under very controlled circumstances statics can be very efficient as it's
simply a direct reference. With read-only scenarios there's little to worry
about although you still have to be aware that some objects of the framework
itself may use internal data to manage their state which can cause odd
behavior when multiple threads access these objects. Remember that ASP.Net
handles each incoming request on a separate thread and each of those threads
shares the same property data.
+++ Rick ----

--

Rick Strahl
West Wind Technologies
http://www.west-wind.com/
http://www.west-wind.com/weblog/
----------------------------------
Making waves on the Web
"Joe Fallon" <jf******@nospa mtwcny.rr.com> wrote in message
news:u3******** *****@TK2MSFTNG P10.phx.gbl...

In another post Kevin Spencer stated: "one should be careful of using static fields, properties, and methods, by understanding what the implications of
such are (e.g. locking static variables when changing because they are not
thread-safe)."

Can someone please elaborate on the pros and cons of using static methods?
(In VB they are called Shared methods.) The MS DAAB uses Shared methods.
This means that all Data Access calls go through this block of code without instantiating an instance. I assumed that this would be a highly scalable
solution. Is this assumption correct? Or are there drawbacks to using shared methods that reduce the scalability? Do multiple users ever "step on each
other"? For example, can UserA end up with UserB's Datareader?

Appreciate any advice.
--
Joe Fallon

[Rick Strahl [MVP]]

Generally static methods should never be a problem. Statics are nice
precisely because you don't need and instance ref first, although I suspect
that the overhead of creating an instance would be minimal in the first
place. More than anything it's about the convenience of having those methods
available directly without setting up an instance. If your methods don't
require class level data and they're self contained they're good canidates
for static methods.

it's static data you have to be potentially aware of for potential
multi-threading lock issues as any data that is static is shared by the
entire ASP.Net application and its AppDomain. I use static data quite a bit
in my apps for storing configuration data and a number of one time loaded
references to reused data of all sorts. If data is read only or only updated
under very controlled circumstances statics can be very efficient as it's
simply a direct reference. With read-only scenarios there's little to worry
about although you still have to be aware that some objects of the framework
itself may use internal data to manage their state which can cause odd
behavior when multiple threads access these objects. Remember that ASP.Net
handles each incoming request on a separate thread and each of those threads
shares the same property data.
+++ Rick ----

--

Rick Strahl
West Wind Technologies
http://www.west-wind.com/
http://www.west-wind.com/weblog/
----------------------------------
Making waves on the Web
"Joe Fallon" <jf******@nospa mtwcny.rr.com> wrote in message
news:u3******** *****@TK2MSFTNG P10.phx.gbl...

In another post Kevin Spencer stated: "one should be careful of using static fields, properties, and methods, by understanding what the implications of
such are (e.g. locking static variables when changing because they are not
thread-safe)."

Can someone please elaborate on the pros and cons of using static methods?
(In VB they are called Shared methods.) The MS DAAB uses Shared methods.
This means that all Data Access calls go through this block of code without instantiating an instance. I assumed that this would be a highly scalable
solution. Is this assumption correct? Or are there drawbacks to using shared methods that reduce the scalability? Do multiple users ever "step on each
other"? For example, can UserA end up with UserB's Datareader?

Appreciate any advice.
--
Joe Fallon

[Joe Fallon]

Rick,
Thanks for the comments.
Just what I was hoping to hear.
--
Joe Fallon

"Rick Strahl [MVP]" <ri********@hot mail.com> wrote in message
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

Generally static methods should never be a problem. Statics are nice
precisely because you don't need and instance ref first, although I suspect that the overhead of creating an instance would be minimal in the first
place. More than anything it's about the convenience of having those methods available directly without setting up an instance. If your methods don't
require class level data and they're self contained they're good canidates
for static methods.

it's static data you have to be potentially aware of for potential
multi-threading lock issues as any data that is static is shared by the
entire ASP.Net application and its AppDomain. I use static data quite a bit in my apps for storing configuration data and a number of one time loaded
references to reused data of all sorts. If data is read only or only updated under very controlled circumstances statics can be very efficient as it's
simply a direct reference. With read-only scenarios there's little to worry about although you still have to be aware that some objects of the framework itself may use internal data to manage their state which can cause odd
behavior when multiple threads access these objects. Remember that ASP.Net
handles each incoming request on a separate thread and each of those threads shares the same property data.
+++ Rick ----

--

Rick Strahl
West Wind Technologies
http://www.west-wind.com/
http://www.west-wind.com/weblog/
----------------------------------
Making waves on the Web
"Joe Fallon" <jf******@nospa mtwcny.rr.com> wrote in message
news:u3******** *****@TK2MSFTNG P10.phx.gbl...

In another post Kevin Spencer stated: "one should be careful of using

static

fields, properties, and methods, by understanding what the implications of such are (e.g. locking static variables when changing because they are not thread-safe)."

Can someone please elaborate on the pros and cons of using static methods? (In VB they are called Shared methods.) The MS DAAB uses Shared methods.
This means that all Data Access calls go through this block of code

without

instantiating an instance. I assumed that this would be a highly scalable solution. Is this assumption correct? Or are there drawbacks to using

shared

methods that reduce the scalability? Do multiple users ever "step on each other"? For example, can UserA end up with UserB's Datareader?

Appreciate any advice.
--
Joe Fallon