https://bugzilla.novell.com/show_bug.cgi?id=421491
https://bugzilla.novell.com/show_bug.cgi?id=421491#c21 --- Comment #21 from Dan McFadyen <d...@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. _______________________________________________ mono-bugs maillist - mono-bugs@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-bugs
