Swapping the object instance in dot net

[Sethu Madhavan]

Hi All

Here i am facing one technical issue related to Swapping the Object Instance
in Dotnet.

e.g..

class Customer{

Order _lastOrder;

void insertOrder (int ID, int quantity, double amount, int productId)

Order currentOrder = new Order(ID, quantity, amount, productID);

currentOrder.Insert();

this._lastOrder = currentOrder

}
this is my class, when i try to swap the currentOrder instance to
_lastOrder, what could happen for the currentOrder object memory, whether it
will destroy immediately or what is the stage. As per the Microsoft
suggestion avoid this type of code because it increases the likelihood of the
object being promoted beyond Gen 0, which delays the object's resources from
being reclaimed.

I am using this type of Swapping in my application very frequently, if it
so, whether memory will grow,

can any one please suggest your valuable inputs in this, by how to handle
this type of scenario.

[Jon Skeet [C# MVP]]

<"=?Utf-8?B?U2V0aHUgTWFkaGF2YW4=?=" <Sethu
Ma******@discussions.microsoft.com>> wrote:

Here i am facing one technical issue related to Swapping the Object Instance
in Dotnet.

e.g..

class Customer{

Order _lastOrder;

void insertOrder (int ID, int quantity, double amount, int productId)

Order currentOrder = new Order(ID, quantity, amount, productID);

currentOrder.Insert();

this._lastOrder = currentOrder

}
this is my class, when i try to swap the currentOrder instance to
_lastOrder, what could happen for the currentOrder object memory, whether it
will destroy immediately or what is the stage.
Assuming there are no other live references to it, it will be collected
next time the generation it lives in is garbage collected.
As per the Microsoft suggestion avoid this type of code because it
increases the likelihood of the object being promoted beyond Gen 0,
which delays the object's resources from being reclaimed.
I don't recall seeing any recommendations particularly against this
type of code. Could you give a link to the page you're talking about?
I am using this type of Swapping in my application very frequently, if it
so, whether memory will grow,

can any one please suggest your valuable inputs in this, by how to handle
this type of scenario.

Well, I wouldn't worry about it, personally. The garbage collector is
pretty good, and while it's worth keeping an eye on the memory to be
sure, you'll probably find it isn't a problem.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Sethu Madhavan]

"Jon Skeet [C# MVP]" wrote:

<"=?Utf-8?B?U2V0aHUgTWFkaGF2YW4=?=" <Sethu
Ma******@discussions.microsoft.com>> wrote:

Here i am facing one technical issue related to Swapping the Object Instance
in Dotnet.

e.g..

class Customer{

Order _lastOrder;

void insertOrder (int ID, int quantity, double amount, int productId)

Order currentOrder = new Order(ID, quantity, amount, productID);

currentOrder.Insert();

this._lastOrder = currentOrder

}
this is my class, when i try to swap the currentOrder instance to
_lastOrder, what could happen for the currentOrder object memory, whether it
will destroy immediately or what is the stage.
Assuming there are no other live references to it, it will be collected
next time the generation it lives in is garbage collected.

As per the Microsoft suggestion avoid this type of code because it
increases the likelihood of the object being promoted beyond Gen 0,
which delays the object's resources from being reclaimed.

I don't recall seeing any recommendations particularly against this
type of code. Could you give a link to the page you're talking about?

the link page is
http://msdn.microsoft.com/library/de...netchapt05.asp

under the paragraph "Prevent the Promotion of Short-Lived Objects"

I am using this type of Swapping in my application very frequently, if it
so, whether memory will grow,

can any one please suggest your valuable inputs in this, by how to handle
this type of scenario.

Well, I wouldn't worry about it, personally. The garbage collector is
pretty good, and while it's worth keeping an eye on the memory to be
sure, you'll probably find it isn't a problem.

Yes Jon this is increasing our application memory usage and goes out of
memory exception problem.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

Sethu,

Because as you, do I try to avoid this kind of code, and normally should the
GC do its work as well with this. If it really that harmful than you can try
to set that global value of course to null to remove the last reference.

Cor

[Cor Ligthert]

Jon,

Assuming there are no other live references to it, it will be collected
next time the generation it lives in is garbage collected.

This is as well a part of our last discussion about that usng "with events"
nothing to do with the "event". However, done in this way (as I wrote) there
would stay forever a last reference as long as the (a kind of toplevel)
object live. That is the reason why I found it wrong code although it does
work.

Well, I wouldn't worry about it, personally. The garbage collector is
pretty good, and while it's worth keeping an eye on the memory to be
sure, you'll probably find it isn't a problem.

However for me in general it is the same as you wrote above,

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no************@planet.nl> wrote:

Assuming there are no other live references to it, it will be collected
next time the generation it lives in is garbage collected.

This is as well a part of our last discussion about that usng "with events"
nothing to do with the "event". However, done in this way (as I wrote) there
would stay forever a last reference as long as the (a kind of toplevel)
object live. That is the reason why I found it wrong code although it does
work.

I don't see the relationship to the other thread. I'm assuming that in
this case the OP really *does* want to keep track of the last order of
a particular customer, in which case I see nothing wrong with the code
at all.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Sethu Madhavan <Se***********@discussions.microsoft.com> wrote:

I don't recall seeing any recommendations particularly against this
type of code. Could you give a link to the page you're talking about?

the link page is
http://msdn.microsoft.com/library/de...ary/en-us/dnpa
g/html/scalenetchapt05.asp

under the paragraph "Prevent the Promotion of Short-Lived Objects"

Right. Personally, I think that's a very bad example. Unless the Order
class has a significant overhead (which it doesn't appear to) I
wouldn't expect that associating one with a Customer would have
significant problems. There's nothing in the code given to really
indicate that Customer is likely to be a very long-lived object.

Whether or not it's appropriate to use this for your particular code
would depend on your actual situation though - could you give more
details?

Well, I wouldn't worry about it, personally. The garbage collector is
pretty good, and while it's worth keeping an eye on the memory to be
sure, you'll probably find it isn't a problem.

Yes Jon this is increasing our application memory usage and goes out of
memory exception problem.

It sounds very unlikely that this is actually the cause of an out of
memory exception. Have you used a profiler to determine this? What does
your actual code look like?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Sethu Madhavan]

We have developed a dotnet application running as windows service.

Background: We are running a resource intensive application, which 1)
Maintain huge chunk of in memory data 2) create Assemblies/AppDomain runtime
3) Spawn multiple threads during runtime 4) process request from multiple
sources parallely.

Issue: Out of memory exception errors may occurs even when significant
amounts of physical memory are still available, which makes the application
unstable.

We tested by installing the .NET framework 1.1 Service pack 1(published
8/30/2004), which specifically talks about this problem. But still we are
getting this problem.
"Jon Skeet [C# MVP]" wrote:

Sethu Madhavan <Se***********@discussions.microsoft.com> wrote:

I don't recall seeing any recommendations particularly against this
type of code. Could you give a link to the page you're talking about?

the link page is
http://msdn.microsoft.com/library/de...ary/en-us/dnpa
g/html/scalenetchapt05.asp

under the paragraph "Prevent the Promotion of Short-Lived Objects"

Right. Personally, I think that's a very bad example. Unless the Order
class has a significant overhead (which it doesn't appear to) I
wouldn't expect that associating one with a Customer would have
significant problems. There's nothing in the code given to really
indicate that Customer is likely to be a very long-lived object.

Whether or not it's appropriate to use this for your particular code
would depend on your actual situation though - could you give more
details?

Well, I wouldn't worry about it, personally. The garbage collector is
pretty good, and while it's worth keeping an eye on the memory to be
sure, you'll probably find it isn't a problem.

Yes Jon this is increasing our application memory usage and goes out of
memory exception problem.

It sounds very unlikely that this is actually the cause of an out of
memory exception. Have you used a profiler to determine this? What does
your actual code look like?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Sethu Madhavan <Se***********@discussions.microsoft.com> wrote:

We have developed a dotnet application running as windows service.

Background: We are running a resource intensive application, which 1)
Maintain huge chunk of in memory data 2) create Assemblies/AppDomain runtime
3) Spawn multiple threads during runtime 4) process request from multiple
sources parallely.

Issue: Out of memory exception errors may occurs even when significant
amounts of physical memory are still available, which makes the application
unstable.

We tested by installing the .NET framework 1.1 Service pack 1(published
8/30/2004), which specifically talks about this problem. But still we are
getting this problem.

If you've still got significant amounts of physical memory available,
this sounds like it could be a .NET bug - it may be worth raising a
problem report with Microsoft directly, particularly if you can
reproduce the problem.

One thing which *might* be happening is that you're running out not of
memory, but of handles (eg file handles). I've a feeling that gets
reported as an out of memory exception too in some situations. Are you
definitely disposing of all unmanaged resources when you've finished
with them?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Sethu Madhavan]

"Jon Skeet [C# MVP]" wrote:

Sethu Madhavan <Se***********@discussions.microsoft.com> wrote:

We have developed a dotnet application running as windows service.

Background: We are running a resource intensive application, which 1)
Maintain huge chunk of in memory data 2) create Assemblies/AppDomain runtime
3) Spawn multiple threads during runtime 4) process request from multiple
sources parallely.

Issue: Out of memory exception errors may occurs even when significant
amounts of physical memory are still available, which makes the application
unstable.

We tested by installing the .NET framework 1.1 Service pack 1(published
8/30/2004), which specifically talks about this problem. But still we are
getting this problem.
If you've still got significant amounts of physical memory available,
this sounds like it could be a .NET bug - it may be worth raising a
problem report with Microsoft directly, particularly if you can
reproduce the problem.

One thing which *might* be happening is that you're running out not of
memory, but of handles (eg file handles). I've a feeling that gets
reported as an out of memory exception too in some situations. Are you
definitely disposing of all unmanaged resources when you've finished
with them?

Yes Jon Skeet we are properly disposing all of our objects, I have one input
that
we are using one wrapper object for Unmanaged code, inside of it also we are
desposing, my thoughts are whether the unmanaged code call will be properly
disposed.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Sethu Madhavan <Se***********@discussions.microsoft.com> wrote:

One thing which *might* be happening is that you're running out not of
memory, but of handles (eg file handles). I've a feeling that gets
reported as an out of memory exception too in some situations. Are you
definitely disposing of all unmanaged resources when you've finished
with them?

Yes Jon Skeet we are properly disposing all of our objects, I have
one input that we are using one wrapper object for Unmanaged code,
inside of it also we are desposing, my thoughts are whether the
unmanaged code call will be properly disposed.

What *exactly* do you mean by "whether the unmanaged code code will be
properly disposed"? A call itself doesn't need to be disposed.

It sounds like you could really do with a profiler to find out what's
taking all your memory. Does it fail in different places each time, or
is it always on the same type of call? If it's the latter, that might
suggest a non-memory related problem.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Sethu Madhavan]

"Jon Skeet [C# MVP]" wrote:

Sethu Madhavan <Se***********@discussions.microsoft.com> wrote:

One thing which *might* be happening is that you're running out not of
memory, but of handles (eg file handles). I've a feeling that gets
reported as an out of memory exception too in some situations. Are you
definitely disposing of all unmanaged resources when you've finished
with them?
Yes Jon Skeet we are properly disposing all of our objects, I have
one input that we are using one wrapper object for Unmanaged code,
inside of it also we are desposing, my thoughts are whether the
unmanaged code call will be properly disposed.

What *exactly* do you mean by "whether the unmanaged code code will be
properly disposed"? A call itself doesn't need to be disposed.

It sounds like you could really do with a profiler to find out what's
taking all your memory. Does it fail in different places each time, or
is it always on the same type of call? If it's the latter, that might
suggest a non-memory related problem.

I am not able to test with the prfiler, because in my application during
runtime i am creating a assemblies i.e. dynamic assemblies, so the profiler
is not able for my application.

We already did some exercise with microsoft supporting team in this, we
asked a dump file when out of memory exception comes, and they analyse this
said that it would be unmanaged component, so we did some fix in that
unmanaged calling wrapper class file. we found some improvement, however we
are still getting this OME problem, is it possible you to analyse the new
dump file, for getting some information.

please let me know any queries/ clarrifications in this.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Sethu Madhavan <Se***********@discussions.microsoft.com> wrote:

It sounds like you could really do with a profiler to find out what's
taking all your memory. Does it fail in different places each time, or
is it always on the same type of call? If it's the latter, that might
suggest a non-memory related problem.

I am not able to test with the prfiler, because in my application during
runtime i am creating a assemblies i.e. dynamic assemblies, so the profiler
is not able for my application.

We already did some exercise with microsoft supporting team in this, we
asked a dump file when out of memory exception comes, and they analyse this
said that it would be unmanaged component, so we did some fix in that
unmanaged calling wrapper class file. we found some improvement, however we
are still getting this OME problem, is it possible you to analyse the new
dump file, for getting some information.

please let me know any queries/ clarrifications in this.

I'm afraid I don't have the time (or the expertise) to analyse the dump
file. I suggest you go back to the Microsoft support team, I'm afraid.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Sethu Madhavan]

"Jon Skeet [C# MVP]" wrote:

Sethu Madhavan <Se***********@discussions.microsoft.com> wrote:

It sounds like you could really do with a profiler to find out what's
taking all your memory. Does it fail in different places each time, or
is it always on the same type of call? If it's the latter, that might
suggest a non-memory related problem.
I am not able to test with the prfiler, because in my application during
runtime i am creating a assemblies i.e. dynamic assemblies, so the profiler
is not able for my application.

We already did some exercise with microsoft supporting team in this, we
asked a dump file when out of memory exception comes, and they analyse this
said that it would be unmanaged component, so we did some fix in that
unmanaged calling wrapper class file. we found some improvement, however we
are still getting this OME problem, is it possible you to analyse the new
dump file, for getting some information.

please let me know any queries/ clarrifications in this.

I'm afraid I don't have the time (or the expertise) to analyse the dump
file. I suggest you go back to the Microsoft support team, I'm afraid.

Jon i need a design requriement, can you please able to give some valuable
suggestions in this.

I need to develop a Logger Component in dotnet, It needs to be supported as
ServicedComponent (COM+) to support Business layer components and Library
Reference to support UI Control.

As per my thoughts it should can have some interface which have a method to
logging the error details,

when it is act as a serviced components it should log into database and when
it act as library reference it should log into xm file.

please let me any further clarrifications requried

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Sethu Madhavan <Se***********@discussions.microsoft.com> wrote:

I'm afraid I don't have the time (or the expertise) to analyse the dump
file. I suggest you go back to the Microsoft support team, I'm afraid.
Jon i need a design requriement, can you please able to give some valuable
suggestions in this.

Maybe - although this sounds like it belongs in a completely new
thread...
I need to develop a Logger Component in dotnet, It needs to be supported as
ServicedComponent (COM+) to support Business layer components and Library
Reference to support UI Control.

As per my thoughts it should can have some interface which have a method to
logging the error details,

when it is act as a serviced components it should log into database and when
it act as library reference it should log into xm file.

please let me any further clarrifications requried

Well, firstly I'd consider using existing logging interfaces - have a
look at log4net to start with: http://logging.apache.org/log4net/

I suspect that it isn't a good idea to tie the configuration directly
to whether it's being used as a serviced component or not - why not
just configure it appropriately in each setting? That way if you later
need it to log to a database even when you're using it from the UI, you
just need to change the configuration rather than a load of assumptions
made in code.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Sethu Madhavan]

"Jon Skeet [C# MVP]" wrote:

Sethu Madhavan <Se***********@discussions.microsoft.com> wrote:

I'm afraid I don't have the time (or the expertise) to analyse the dump
file. I suggest you go back to the Microsoft support team, I'm afraid.
Jon i need a design requriement, can you please able to give some valuable
suggestions in this.

Maybe - although this sounds like it belongs in a completely new
thread...

I need to develop a Logger Component in dotnet, It needs to be supported as
ServicedComponent (COM+) to support Business layer components and Library
Reference to support UI Control.

As per my thoughts it should can have some interface which have a method to
logging the error details,

when it is act as a serviced components it should log into database and when
it act as library reference it should log into xm file.

please let me any further clarrifications requried

Well, firstly I'd consider using existing logging interfaces - have a
look at log4net to start with: http://logging.apache.org/log4net/

I suspect that it isn't a good idea to tie the configuration directly
to whether it's being used as a serviced component or not - why not
just configure it appropriately in each setting? That way if you later
need it to log to a database even when you're using it from the UI, you
just need to change the configuration rather than a load of assumptions
made in code.

Your are right my component should act as configured in xml, but my thoughts
is how logger component can support both logging in Service component and
alos in UI controller.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Sethu Madhavan <Se***********@discussions.microsoft.com> wrote:

I suspect that it isn't a good idea to tie the configuration directly
to whether it's being used as a serviced component or not - why not
just configure it appropriately in each setting? That way if you later
need it to log to a database even when you're using it from the UI, you
just need to change the configuration rather than a load of assumptions
made in code.

Your are right my component should act as configured in xml, but my thoughts
is how logger component can support both logging in Service component and
alos in UI controller.

Well, what do you think would be the problem?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too