Instantiate an object in two ways???

[J-T]

I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return m_RsProxy;}}
}


B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}


I personally like the second one.Some people say that the second one is not
good because everytime you call doSomthing(..) a new instance is created.I
do agree with it ,but the first approach in an aasp.net application has the
same demrits ,unless you put the object inside application variable or
session variable and persist it.Other wise when you are done working with
the object it is ready for the garbage collector to be collected and when
the second request arrives ,if the object is collected then you need to
create another instance.Am I righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks

 

[Marina]

The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

However, you are opening yourself up for potential threading issues. If 2
people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time? Depending on
what your object does, you may need to synchronize access to it. Which could
potentially slow down your app if it takes a long time to complete its work,
as well as adding complexity to anything using it, because now it has to
worry about making sure it is safe to access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation of
this object is not expensive, and it will be garbage collected when the
request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other problems.

 

[J-T]

The first way, you will have one instance for the entire asp.net app. It

will not be garbage collected.

Why it is not gargage collected? Imagine a request makes this object be
created and when the request is done the object is there ,may hang around
for a while and if no one else (no other request) uses that one ,then it has
no reference to it and it's ready to be garbage collected.right?

However, you are opening yourself up for potential threading issues. If 2
people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time?

ASP.NET application is a multi-threaded one and there is always multiple
threads working with objects it create,There is no way of getting rid of
multiple threads working at the same time ,right?

Thanks for your reply.

The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

However, you are opening yourself up for potential threading issues. If 2
people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time? Depending on
what your object does, you may need to synchronize access to it. Which
could potentially slow down your app if it takes a long time to complete
its work, as well as adding complexity to anything using it, because now
it has to worry about making sure it is safe to access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation of
this object is not expensive, and it will be garbage collected when the
request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other problems.

I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return m_RsProxy;}}
}


B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}


I personally like the second one.Some people say that the second one is
not good because everytime you call doSomthing(..) a new instance is
created.I do agree with it ,but the first approach in an aasp.net
application has the same demrits ,unless you put the object inside
application variable or session variable and persist it.Other wise when
you are done working with the object it is ready for the garbage
collector to be collected and when the second request arrives ,if the
object is collected then you need to create another instance.Am I righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks

 

[Marina]

1. No, it is not right. When it is a static object, it means it belongs to
class type. And there is only one of that. Once it is instantiated, it stays
around for the lifetime of the application. Meaning until asp.net is shut
down or recycled.

2. ASP.NET is multithreaded - and if it wasn't, you would have a very very
slow application. This is why I suggested having the static object is not a
way to go - you have to start worrying about multiple threads accessing your
object at the same time.

The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

Why it is not gargage collected? Imagine a request makes this object be
created and when the request is done the object is there ,may hang around
for a while and if no one else (no other request) uses that one ,then it
has no reference to it and it's ready to be garbage collected.right?

However, you are opening yourself up for potential threading issues. If 2
people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time?

ASP.NET application is a multi-threaded one and there is always multiple
threads working with objects it create,There is no way of getting rid of
multiple threads working at the same time ,right?

Thanks for your reply.

The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

However, you are opening yourself up for potential threading issues. If 2
people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time? Depending on
what your object does, you may need to synchronize access to it. Which
could potentially slow down your app if it takes a long time to complete
its work, as well as adding complexity to anything using it, because now
it has to worry about making sure it is safe to access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation of
this object is not expensive, and it will be garbage collected when the
request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other problems.

I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return m_RsProxy;}}
}


B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}


I personally like the second one.Some people say that the second one is
not good because everytime you call doSomthing(..) a new instance is
created.I do agree with it ,but the first approach in an aasp.net
application has the same demrits ,unless you put the object inside
application variable or session variable and persist it.Other wise when
you are done working with the object it is ready for the garbage
collector to be collected and when the second request arrives ,if the
object is collected then you need to create another instance.Am I righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks

 

[J-T]

About the first method,

As you can see ,it is using an static variable ,and I think static variables
are stored in the heap and objects stored on the heap can be accessed by all
threads.My object is a readonly object.what I mean by read only is that none
of the threads are trying to change it ,they only want to use it,so none of
those threads lock the object.Having said all this,do you still think that I
have still thread issue.

Thanks

1. No, it is not right. When it is a static object, it means it belongs
to class type. And there is only one of that. Once it is instantiated, it
stays around for the lifetime of the application. Meaning until asp.net is
shut down or recycled.

2. ASP.NET is multithreaded - and if it wasn't, you would have a very very
slow application. This is why I suggested having the static object is not
a way to go - you have to start worrying about multiple threads accessing
your object at the same time.

The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

Why it is not gargage collected? Imagine a request makes this object be
created and when the request is done the object is there ,may hang around
for a while and if no one else (no other request) uses that one ,then it
has no reference to it and it's ready to be garbage collected.right?

However, you are opening yourself up for potential threading issues. If
2 people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time?

ASP.NET application is a multi-threaded one and there is always multiple
threads working with objects it create,There is no way of getting rid of
multiple threads working at the same time ,right?

Thanks for your reply.

The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

However, you are opening yourself up for potential threading issues. If
2 people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time? Depending on
what your object does, you may need to synchronize access to it. Which
could potentially slow down your app if it takes a long time to complete
its work, as well as adding complexity to anything using it, because now
it has to worry about making sure it is safe to access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation
of this object is not expensive, and it will be garbage collected when
the request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other
problems.

I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials =
System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return m_RsProxy;}}
}


B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}


I personally like the second one.Some people say that the second one is
not good because everytime you call doSomthing(..) a new instance is
created.I do agree with it ,but the first approach in an aasp.net
application has the same demrits ,unless you put the object inside
application variable or session variable and persist it.Other wise when
you are done working with the object it is ready for the garbage
collector to be collected and when the second request arrives ,if the
object is collected then you need to create another instance.Am I righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks

 

[J-T]

If your answer to my previous post is NO,can you guid me to some references
I can read more about that specific behavior?

Thanks a lot for follwoing up this.

1. No, it is not right. When it is a static object, it means it belongs
to class type. And there is only one of that. Once it is instantiated, it
stays around for the lifetime of the application. Meaning until asp.net is
shut down or recycled.

2. ASP.NET is multithreaded - and if it wasn't, you would have a very very
slow application. This is why I suggested having the static object is not
a way to go - you have to start worrying about multiple threads accessing
your object at the same time.

The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

Why it is not gargage collected? Imagine a request makes this object be
created and when the request is done the object is there ,may hang around
for a while and if no one else (no other request) uses that one ,then it
has no reference to it and it's ready to be garbage collected.right?

However, you are opening yourself up for potential threading issues. If
2 people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time?

ASP.NET application is a multi-threaded one and there is always multiple
threads working with objects it create,There is no way of getting rid of
multiple threads working at the same time ,right?

Thanks for your reply.

The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

However, you are opening yourself up for potential threading issues. If
2 people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time? Depending on
what your object does, you may need to synchronize access to it. Which
could potentially slow down your app if it takes a long time to complete
its work, as well as adding complexity to anything using it, because now
it has to worry about making sure it is safe to access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation
of this object is not expensive, and it will be garbage collected when
the request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other
problems.

I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials =
System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return m_RsProxy;}}
}


B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}


I personally like the second one.Some people say that the second one is
not good because everytime you call doSomthing(..) a new instance is
created.I do agree with it ,but the first approach in an aasp.net
application has the same demrits ,unless you put the object inside
application variable or session variable and persist it.Other wise when
you are done working with the object it is ready for the garbage
collector to be collected and when the second request arrives ,if the
object is collected then you need to create another instance.Am I righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks

 

[Marina]

If the object will be used for read only purposes, then going the static
route is fine.

About the first method,

As you can see ,it is using an static variable ,and I think static
variables are stored in the heap and objects stored on the heap can be
accessed by all threads.My object is a readonly object.what I mean by read
only is that none of the threads are trying to change it ,they only want
to use it,so none of those threads lock the object.Having said all this,do
you still think that I have still thread issue.

Thanks

1. No, it is not right. When it is a static object, it means it belongs
to class type. And there is only one of that. Once it is instantiated, it
stays around for the lifetime of the application. Meaning until asp.net
is shut down or recycled.

2. ASP.NET is multithreaded - and if it wasn't, you would have a very
very slow application. This is why I suggested having the static object
is not a way to go - you have to start worrying about multiple threads
accessing your object at the same time.

The first way, you will have one instance for the entire asp.net app.
It will not be garbage collected.
Why it is not gargage collected? Imagine a request makes this object be
created and when the request is done the object is there ,may hang
around for a while and if no one else (no other request) uses that one
,then it has no reference to it and it's ready to be garbage
collected.right?


However, you are opening yourself up for potential threading issues. If
2 people make a request at the same time, what if both their threads
are accessing this one instance of the object at the same time?

ASP.NET application is a multi-threaded one and there is always multiple
threads working with objects it create,There is no way of getting rid of
multiple threads working at the same time ,right?

Thanks for your reply.



The first way, you will have one instance for the entire asp.net app.
It will not be garbage collected.

However, you are opening yourself up for potential threading issues. If
2 people make a request at the same time, what if both their threads
are accessing this one instance of the object at the same time?
Depending on what your object does, you may need to synchronize access
to it. Which could potentially slow down your app if it takes a long
time to complete its work, as well as adding complexity to anything
using it, because now it has to worry about making sure it is safe to
access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation
of this object is not expensive, and it will be garbage collected when
the request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other
problems.

I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials =
System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return
m_RsProxy;}}
}


B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials =
System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}


I personally like the second one.Some people say that the second one
is not good because everytime you call doSomthing(..) a new instance
is created.I do agree with it ,but the first approach in an aasp.net
application has the same demrits ,unless you put the object inside
application variable or session variable and persist it.Other wise
when you are done working with the object it is ready for the garbage
collector to be collected and when the second request arrives ,if the
object is collected then you need to create another instance.Am I
righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks

 

[J-T]

Thanks a lot for your nice help

If the object will be used for read only purposes, then going the static
route is fine.

About the first method,

As you can see ,it is using an static variable ,and I think static
variables are stored in the heap and objects stored on the heap can be
accessed by all threads.My object is a readonly object.what I mean by
read only is that none of the threads are trying to change it ,they only
want to use it,so none of those threads lock the object.Having said all
this,do you still think that I have still thread issue.

Thanks

1. No, it is not right. When it is a static object, it means it belongs
to class type. And there is only one of that. Once it is instantiated,
it stays around for the lifetime of the application. Meaning until
asp.net is shut down or recycled.

2. ASP.NET is multithreaded - and if it wasn't, you would have a very
very slow application. This is why I suggested having the static object
is not a way to go - you have to start worrying about multiple threads
accessing your object at the same time.

The first way, you will have one instance for the entire asp.net app.
It will not be garbage collected.
Why it is not gargage collected? Imagine a request makes this object
be created and when the request is done the object is there ,may hang
around for a while and if no one else (no other request) uses that one
,then it has no reference to it and it's ready to be garbage
collected.right?


However, you are opening yourself up for potential threading issues.
If 2 people make a request at the same time, what if both their
threads are accessing this one instance of the object at the same
time?

ASP.NET application is a multi-threaded one and there is always
multiple threads working with objects it create,There is no way of
getting rid of multiple threads working at the same time ,right?

Thanks for your reply.



The first way, you will have one instance for the entire asp.net app.
It will not be garbage collected.

However, you are opening yourself up for potential threading issues.
If 2 people make a request at the same time, what if both their
threads are accessing this one instance of the object at the same
time? Depending on what your object does, you may need to synchronize
access to it. Which could potentially slow down your app if it takes a
long time to complete its work, as well as adding complexity to
anything using it, because now it has to worry about making sure it is
safe to access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation
of this object is not expensive, and it will be garbage collected when
the request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other
problems.

I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials =
System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return
m_RsProxy;}}
}


B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials =
System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}


I personally like the second one.Some people say that the second one
is not good because everytime you call doSomthing(..) a new instance
is created.I do agree with it ,but the first approach in an aasp.net
application has the same demrits ,unless you put the object inside
application variable or session variable and persist it.Other wise
when you are done working with the object it is ready for the garbage
collector to be collected and when the second request arrives ,if the
object is collected then you need to create another instance.Am I
righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks