ODP.NET Dispose bug

  • Thread starter Thread starter John
  • Start date Start date
J

John

My app running under iis was experiencing crashes when I started using
ODP.NET 9.2.0.4.01, with the Oracle client 9.2.0.1.0 to replace legacy
ADO calls. (I also tried with the new 10 client and ODP.NET 10 with
the same behavior). After a couple of weeks of painfully unfruitfull
debugging and help from MS techies, I finally discovered that the
app's stability issues were being caused by multiple calls to the
Dispose methods of OracleConnection,and/or OracleCommand and/or
OracleDataReader classes. I didn't have time to investigate which of
these objects was the culprit, or under exactly what circumstances
calling Dispose twice would cause problems, only that the problem
occured when these objects where finalized after having called Dispose
more than once. From what the MS techies tell me, one of these objects
tries to free memory that has already been freed.

According to this, Dispose should be callable mutliple times without
side effects.
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconImplementingDisposeMethod.asp

I don't have time to look into this any further. Had I more details I
would open a bug with Oracle. Please add more info if you have
experienced this problem, hopefully someone will pick up the trail
where I have left off.
 
Dispose called multiple times is not a problem with .NET Framework classes.
ODP.NET is a third party set of components (Oracle), and may not have the
same rules apply.

If I remember, ODP.NET is a set of java classes with .NET wrappers. As Java
is managed, it should also be safe to have a multiple dispose(). However, it
is possible Oracle coded ODP.NET for speed and moved outside of the memory
sandbox both .NET and Java impose. If so, all bets are off and memory that
has been cleared could be cleared again ... with disaterous results.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Just a note that this is only a guideline - calling multiple times Dispose
should be allowed.
It depends on actual implementation if it can be done, but yes, .net
framework classes should/are supporting it.
 
Cowboy said:
Dispose called multiple times is not a problem with .NET Framework classes.
ODP.NET is a third party set of components (Oracle), and may not have the
same rules apply.

If I remember, ODP.NET is a set of java classes with .NET wrappers. As Java
is managed, it should also be safe to have a multiple dispose(). However, it
is possible Oracle coded ODP.NET for speed and moved outside of the memory
sandbox both .NET and Java impose. If so, all bets are off and memory that
has been cleared could be cleared again ... with disaterous results.
Click to expand...

ODP.NET is .NET code calling into the CLI of the Oracle client. So
basicly a wrapper around unmanaged code, however the wrapper is pretty
big at times.

Calling dispose more than once can cause problems if ODP.NET doesn't
track if it has disposed an unmanaged resource already.

Oracle had 9.2.0.410 online for some time, which had some bugfixes but
it was removed lately because it caused several other problems.

Frans
--
 
Just got back from work... ODP.Net bites! We had to pull out a second
version of our software from production because of ODP.Net. I'm really
disapointed with Oracle support too, I called them and they never
returned my phone call.

Anyway this time it seems to be a handle leak of some sort. No details
yet, but it cause all five production machine to refuse incoming
request for an hour, all at the same time (within 30 minutes) at which
point we rolled back to the previous version.

The load is distributed round-robin on all five servers, so the timing
of this leads me to seriously suspect a leak, and the handle count
seemed to be continously rising when we first tried to fix them with a
resart.

It's a good thing this version only consisted of changes to the
database provider. I can say with assurance that these problems are
caused by ODP.Net and, in disater situations like today, we can
rollback to the previous in a snap. More details as I get them, that
is if I'm >allowed< to desperately try to make this work.
 
Just got back from work... ODP.Net bites! We had to pull out a second
version of our software from production because of ODP.Net. I'm really
disapointed with Oracle support too, I called them and they never
returned my phone call.

Anyway this time it seems to be a handle leak of some sort. No details
yet, but it cause all five production machine to refuse incoming
request for an hour, all at the same time (within 30 minutes) at which
point we rolled back to the previous version.

The load is distributed round-robin on all five servers, so the timing
of this leads me to seriously suspect a leak, and the handle count
seemed to be continously rising when we first tried to fix them with a
resart.

It's a good thing this version only consisted of changes to the
database provider. I can say with assurance that these problems are
caused by ODP.Net and, in disater situations like today, we can
rollback to the previous in a snap. More details as I get them, that
is if I'm >allowed< to desperately try to make this work.
Click to expand...

Please excuse my ignorance. What is ODP.NET?
Otis Mukinfus
http://www.otismukinfus.com
 
I know this is a very old thread, but thought it might be worth posting something as it came up in my Google search results and what we found out might help others.

We ran into issues with IIS worker threads crashing and Oracle support was able to direct us towards cases we were not properly disposing of parameters and their values. See this link below for a more detailed discussion of what we ended up doing to resolve the issue.

http://www.fromthefiefdom.com/what-to-dispose-in-oracle-odpnet
 
Back
Top