Singleton in web service?

[Bob]

Does anyone know of any adverse affects of using singleton data access
objects in an ASP.NET Web Service? I've been forced to implement it this way
but it just doesn't seem right to me. I haven't been able to find a single
example of someone doing it this way and that's usually not a good sign. I'm
afraid that there may be subtle problems that won't show up quickly because
the production environment will not be hitting the web service at a high
rate. Of course I'm also concerned about not subtle problems as well but
they're easier to find.

--
Thanks,
Bob

[Scott Allen]

As long as the singleton doesn't maintain state, it's a reasonable
design. The Microsoft Data Access block class uses all static methods
- which is not a textbook singleton design, but does function the
similarly.

The real problem is state. If the singleton uses fields to store data
between method calls, then you need to be multi-threaded safe, which
can be a performance hit. The DAB does maintain some state (it caches
stored procedure parameter information like names and types) and it
uses locking to avoid corruptions. I'd think MS tested this and
determined it was worth the additional complexity, and overall in this
case the code probably performs better with the caching.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Tue, 21 Dec 2004 11:05:04 -0800, Bob
<Bo*@discussions.microsoft.com> wrote:

Does anyone know of any adverse affects of using singleton data access
objects in an ASP.NET Web Service? I've been forced to implement it this way
but it just doesn't seem right to me. I haven't been able to find a single
example of someone doing it this way and that's usually not a good sign. I'm
afraid that there may be subtle problems that won't show up quickly because
the production environment will not be hitting the web service at a high
rate. Of course I'm also concerned about not subtle problems as well but
they're easier to find.

[Bob]

Thanks Scott. I'm not maintaining state and the consruction is thread safe
so I'm alright there. Do you understand where a singleton is maintained
between calls to a web service? We're not storing the instance in
application state or anywhere else explicitly but it does seem to persist.
This is what worries me the most about this design, not knowing how it's
persisted. I always thought that web services should be designed without any
state between calls, except for remoting singletons which this is not. What
gets me is that the data access classes are tiny and the overhead to create
and destroy on each call it would be trivial compared to the actual data
access.

"Scott Allen" wrote:

As long as the singleton doesn't maintain state, it's a reasonable
design. The Microsoft Data Access block class uses all static methods
- which is not a textbook singleton design, but does function the
similarly.

The real problem is state. If the singleton uses fields to store data
between method calls, then you need to be multi-threaded safe, which
can be a performance hit. The DAB does maintain some state (it caches
stored procedure parameter information like names and types) and it
uses locking to avoid corruptions. I'd think MS tested this and
determined it was worth the additional complexity, and overall in this
case the code probably performs better with the caching.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Tue, 21 Dec 2004 11:05:04 -0800, Bob
<Bo*@discussions.microsoft.com> wrote:

Does anyone know of any adverse affects of using singleton data access
objects in an ASP.NET Web Service? I've been forced to implement it this way
but it just doesn't seem right to me. I haven't been able to find a single
example of someone doing it this way and that's usually not a good sign. I'm
afraid that there may be subtle problems that won't show up quickly because
the production environment will not be hitting the web service at a high
rate. Of course I'm also concerned about not subtle problems as well but
they're easier to find.

[Scott Allen]

Are there any static fields that reference the singleton? If there is
any outstanding reference to the object the garabage collector won't
reclaim the object. How do you get a reference to the singleton to
make a data access call?

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Tue, 21 Dec 2004 16:07:01 -0800, Bob
<Bo*@discussions.microsoft.com> wrote:

Thanks Scott. I'm not maintaining state and the consruction is thread safe
so I'm alright there. Do you understand where a singleton is maintained
between calls to a web service? We're not storing the instance in
application state or anywhere else explicitly but it does seem to persist.
This is what worries me the most about this design, not knowing how it's
persisted. I always thought that web services should be designed without any
state between calls, except for remoting singletons which this is not. What
gets me is that the data access classes are tiny and the overhead to create
and destroy on each call it would be trivial compared to the actual data
access.

"Scott Allen" wrote:

As long as the singleton doesn't maintain state, it's a reasonable
design. The Microsoft Data Access block class uses all static methods
- which is not a textbook singleton design, but does function the
similarly.

The real problem is state. If the singleton uses fields to store data
between method calls, then you need to be multi-threaded safe, which
can be a performance hit. The DAB does maintain some state (it caches
stored procedure parameter information like names and types) and it
uses locking to avoid corruptions. I'd think MS tested this and
determined it was worth the additional complexity, and overall in this
case the code probably performs better with the caching.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Tue, 21 Dec 2004 11:05:04 -0800, Bob
<Bo*@discussions.microsoft.com> wrote:

>Does anyone know of any adverse affects of using singleton data access
>objects in an ASP.NET Web Service? I've been forced to implement it this way
>but it just doesn't seem right to me. I haven't been able to find a single
>example of someone doing it this way and that's usually not a good sign. I'm
>afraid that there may be subtle problems that won't show up quickly because
>the production environment will not be hitting the web service at a high
>rate. Of course I'm also concerned about not subtle problems as well but
>they're easier to find.

[Bob]

Actually I have been keeping the singleton in a non-static field in the class
that uses the singleton. The constructor of the using class gets the
singleton instance via an "Instance" method of the singleton and assigns it
to the field. Member methods then use the member field for data access. To
make matters a little more complicated there are 2 levels of singletons. The
web service exposes 2 classes, each class uses a singleton instance of a
manager class which in turn uses a singleton instance of a data access class
(all the singletons are to different classes). Do you think it is better to
just get the instance inside each method that is going to use a singleton?
That is easy to do, I was just trying to save a few lines of code because one
of the classes has quite a few methods exposed and each needs access to its
singleton. I understand how these things work in regular apps (although I
generally avoid them) but I don't really understand the life cycle and
application domain of web services. Thanks for your help, I really
appreciate it.

"Scott Allen" wrote:

Are there any static fields that reference the singleton? If there is
any outstanding reference to the object the garabage collector won't
reclaim the object. How do you get a reference to the singleton to
make a data access call?

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Tue, 21 Dec 2004 16:07:01 -0800, Bob
<Bo*@discussions.microsoft.com> wrote:

Thanks Scott. I'm not maintaining state and the consruction is thread safe
so I'm alright there. Do you understand where a singleton is maintained
between calls to a web service? We're not storing the instance in
application state or anywhere else explicitly but it does seem to persist.
This is what worries me the most about this design, not knowing how it's
persisted. I always thought that web services should be designed without any
state between calls, except for remoting singletons which this is not. What
gets me is that the data access classes are tiny and the overhead to create
and destroy on each call it would be trivial compared to the actual data
access.

"Scott Allen" wrote:

As long as the singleton doesn't maintain state, it's a reasonable
design. The Microsoft Data Access block class uses all static methods
- which is not a textbook singleton design, but does function the
similarly.

The real problem is state. If the singleton uses fields to store data
between method calls, then you need to be multi-threaded safe, which
can be a performance hit. The DAB does maintain some state (it caches
stored procedure parameter information like names and types) and it
uses locking to avoid corruptions. I'd think MS tested this and
determined it was worth the additional complexity, and overall in this
case the code probably performs better with the caching.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Tue, 21 Dec 2004 11:05:04 -0800, Bob
<Bo*@discussions.microsoft.com> wrote:

>Does anyone know of any adverse affects of using singleton data access
>objects in an ASP.NET Web Service? I've been forced to implement it this way
>but it just doesn't seem right to me. I haven't been able to find a single
>example of someone doing it this way and that's usually not a good sign. I'm
>afraid that there may be subtle problems that won't show up quickly because
>the production environment will not be hitting the web service at a high
>rate. Of course I'm also concerned about not subtle problems as well but
>they're easier to find.

[Scott Allen]

The app domain in a web service is a little more 'fragile' in a way,
or perhaps more 'robust' - depending on your point of view. :)

I say this because there are many forces that can control the lifetime
of the app domain. For instance, IIS can be configured to recycle the
app domain if certain thresholds are met, the runtime will start a new
app domain if the config file changes, and so on.

I discussed this a bit in an article, but I think you'll know this.
http://odetocode.com/Articles/305.aspx

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Wed, 22 Dec 2004 18:11:02 -0800, Bob
<Bo*@discussions.microsoft.com> wrote:

Actually I have been keeping the singleton in a non-static field in the class
that uses the singleton. The constructor of the using class gets the
singleton instance via an "Instance" method of the singleton and assigns it
to the field. Member methods then use the member field for data access. To
make matters a little more complicated there are 2 levels of singletons. The
web service exposes 2 classes, each class uses a singleton instance of a
manager class which in turn uses a singleton instance of a data access class
(all the singletons are to different classes). Do you think it is better to
just get the instance inside each method that is going to use a singleton?
That is easy to do, I was just trying to save a few lines of code because one
of the classes has quite a few methods exposed and each needs access to its
singleton. I understand how these things work in regular apps (although I
generally avoid them) but I don't really understand the life cycle and
application domain of web services. Thanks for your help, I really
appreciate it.

"Scott Allen" wrote:

Are there any static fields that reference the singleton? If there is
any outstanding reference to the object the garabage collector won't
reclaim the object. How do you get a reference to the singleton to
make a data access call?

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Tue, 21 Dec 2004 16:07:01 -0800, Bob
<Bo*@discussions.microsoft.com> wrote:

>Thanks Scott. I'm not maintaining state and the consruction is thread safe
>so I'm alright there. Do you understand where a singleton is maintained
>between calls to a web service? We're not storing the instance in
>application state or anywhere else explicitly but it does seem to persist.
>This is what worries me the most about this design, not knowing how it's
>persisted. I always thought that web services should be designed without any
>state between calls, except for remoting singletons which this is not. What
>gets me is that the data access classes are tiny and the overhead to create
>and destroy on each call it would be trivial compared to the actual data
>access.
>
>"Scott Allen" wrote:
>
>> As long as the singleton doesn't maintain state, it's a reasonable
>> design. The Microsoft Data Access block class uses all static methods
>> - which is not a textbook singleton design, but does function the
>> similarly.
>>
>> The real problem is state. If the singleton uses fields to store data
>> between method calls, then you need to be multi-threaded safe, which
>> can be a performance hit. The DAB does maintain some state (it caches
>> stored procedure parameter information like names and types) and it
>> uses locking to avoid corruptions. I'd think MS tested this and
>> determined it was worth the additional complexity, and overall in this
>> case the code probably performs better with the caching.
>>
>> --
>> Scott
>> http://www.OdeToCode.com/blogs/scott/
>>
>> On Tue, 21 Dec 2004 11:05:04 -0800, Bob
>> <Bo*@discussions.microsoft.com> wrote:
>>
>> >Does anyone know of any adverse affects of using singleton data access
>> >objects in an ASP.NET Web Service? I've been forced to implement it this way
>> >but it just doesn't seem right to me. I haven't been able to find a single
>> >example of someone doing it this way and that's usually not a good sign. I'm
>> >afraid that there may be subtle problems that won't show up quickly because
>> >the production environment will not be hitting the web service at a high
>> >rate. Of course I'm also concerned about not subtle problems as well but
>> >they're easier to find.
>>
>>