Ticket Hash: | 85c35b6489e07dfa157e65e509936c4da731f40f | |||
Title: | Unexpected connection garbage collecting | |||
Status: | Closed | Type: | Incident | |
Severity: | Critical | Priority: | Medium | |
Subsystem: | Connection | Resolution: | Works_As_Designed | |
Last Modified: | 2013-05-28 09:29:14 | |||
Version Found In: | 1.0.85 | |||
User Comments: | ||||
anonymous added on 2013-05-24 08:47:34:
(text/x-fossil-plain)
Early I migrated my company software from the old unsupported assembly to your new one. I encapsulated a connection instance into my helper class. Sometimes the instance become invalid (destroyed from the garbage collector!). To avoid this issue I had to invoke GC.SuppressFinalize on the connection instance, and then manually invoke the dispose method from the helper class disposition event. Thank you! Antonio Petricca mistachkin added on 2013-05-24 09:29:24: (text/x-fossil-plain) If you have an outstanding reference to the connection object, the CLR should not try to garbage collect it (unless the object containing the connection object is also being garbage collected and there are no other references to said connection object). Does this happen consistently? Do you have any other details about the behavior being seen? anonymous added on 2013-05-24 10:03:23: (text/x-fossil-plain) "If you have an outstanding reference to the connection object, the CLR should not try to garbage collect it (unless the object containing the connection object is also being garbage collected and there are no other references to said connection object)." You're right, but I've a permanent reference to it for the whole helper class lifecycle. "Does this happen consistently? " Yes, it does! "Do you have any other details about the behavior being seen?" Sorry, I haven't any other details at this moment. mistachkin added on 2013-05-24 20:40:26: (text/x-fossil-plain) Are you using the connection with "using" blocks (or passing it to another object that might be)? If so, that will call Dispose on the connection when the "using" block is exited. anonymous added on 2013-05-27 06:46:51: (text/x-fossil-plain) I'm creating a reference to the connection in my class constructor, and I null it on the dispose method implementation, but sometimes it was garbage collected before the owner object!!! mistachkin added on 2013-05-27 21:26:29: (text/x-fossil-plain) Does that mean that your object was already being disposed at the time? If so, bear in mind that the CLR does not guarantee the garbage collection order for objects (i.e. if there are two objects in need of garbage collection, object 1 may be garbage collected before -OR- after object 2). anonymous added on 2013-05-28 08:47:52: (text/x-fossil-plain) Yes, that's what's happening. Why the CLR collects objects referenced by another object?!? mistachkin added on 2013-05-28 09:29:14: (text/x-fossil-plain) The finalization used by garbage collector in the CLR is not deterministic. If an object is being finalized, any objects referenced by its fields are potentially eligible for finalization as well (i.e. you cannot rely on fields of an object being finalized as being available if they refer to other objects that can be "invalidated" via finalization, such as those that implement IDisposable). |