[Mono-bugs] [Bug 421491] "Could not allocate new OCI Handle of type Statement" message when accessing Oracle

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=421491

https://bugzilla.novell.com/show_bug.cgi?id=421491#c21


--- Comment #21 from Dan McFadyen <danm at cryptocard.com> 2011-08-15 15:20:09 UTC ---
Created an attachment (id=445821)
 --> (http://bugzilla.novell.com/attachment.cgi?id=445821)
OracleConnection.cs and OracleConnectionPool.cs


I've read over the files and read some comments from Chris Brown, and there
were a couple things pointed out.

Pointed out by Chris Brown:
 - OracleConnectionPool.cs
   - I think the 'lock (list)' that you have added around the adding and
removing to the list in GetConnection is redundant. The very first level of
braces in that function a lock on the same object.
   - At line 86:  if (connection == null && list.Count < PoolMaxSize)
     - From the previous code, the intent of this statement is to prevent
creating more connections than the maximum pool size. The problem is that the
list here doesn't maintain references to all the OciGlue objects, just the
unused ones. If every OciGlue class is currently in used, then list.Count will
always be zero. This means that there is no maximum pool size any more. The int
activeConnections you removed was a count of all connections, including the
ones not currently in the pool.
   - I can't see any references to the bool disposed.

Now, there is a lot of good stuff. The OciGlue looks like it will be cleaned up
correctly and properly disposed of now. Aside from the connection pool issue
above, the original issue seems solved. But there is something I noticed with
even my bad attempt at a fix.

The code wasn't broken for trying to add the OciGlue back into the connection
pool. It was broken for trying to add a OciGlue object that had been disposed
back into the pool. This only happens because when the GC goes after the
connection, the OciGlue is only referenced by the connection, and because of
that it goes down with it. If we keep a reference to the OciGlue outside of the
connection, and in the pool, then when the connection gets GC'd it will instead
add a valid OciGlue reference back into the pool. This would keep the intent of
the code (and pooling) intact, so leaked connections are still correctly
pooled.

If a second list was added to the connection pool, one that maintained a list
of all OciGlue objects it ever made, it could be used to fix the issue at line
86, as it would be a valid test against the maximum pool size, and it would
also keep the OciGlue objects alive while the connection objects are destroyed.
This in turn means that the original logic in the OracleConnection class can be
left alone as even if the GC is doing the disposing, what it's doing will be
correct.

The attachment contains copies of your files modified to this end as an
example.

Also, I noticed you fixed up the bug you'd get if you called Close more than
once. Thanks.

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.