This content has been marked as final. Show 2 replies
1) "how the pooling parameters are set up initially": refer to the odp.net documentation, it tells you what all the default parameters are. The key parameter in this case would likely be "max pool size" which defaults to 100.
2) "maxconnections in machine.config": I looked at that note which doesnt contain very much detail, but couldnt force a problem. maxconnection="2" is apparently the default, it's what mine is set to, and I can open 100 connections without problem. It may be that theres another setting that can affect this (I doubt the guy who wrote the note just made the info up) but I dont know what that is top of my head.
3) the pooling parameters can only be set in the connect string itself. You could certainly store the settings in a System.Configuration.ConfigurationSettings.AppSettings file however.
4) "Connection request timed out" is typically not an Oracle software problem, but more frequently an issue with code not cleaning up after itself properly. To confirm whether you've hit "max pool size", check v$session; how many actual connections does that app have? Make sure you're closing and disposing the connection, and additionally the command, reader, etc, under all circumstances (ie, a finally block).
Hope that helps,
hi Greg, thanks for the support. We did the following to solve our problems:
- updated to ODP version 220.127.116.11. There was one drawback: if you install a new version of the web-application, compiled on a machine with this ODP-version, it does not seem to run on a machine still running the older (18.104.22.168) odp-version. So we were forced to install it on the production machine too, luckily without problems for the other applications.
- we implemented error-logging (should have done that in the first place...) and solved a number of programming errors, that came up thanks to that logging
- most of the connection time-out problems appeared to be caused by not closing/disposing commands and connections at the right place / moment. We did a careful code-review to sort these things out, and that seems to be successfull.
- The error-logging itself succeeded after giving another user (not the machine-user) write autorisations on the error-log directory. This is probably because it works different on a Windows server 2003 machine.