问题
I am writing a nightly job to move data from SQL Server to Oracle using ODP.NET.
We use around 100 connection objects(independent of data) and we don't expect more than 1500 rows to transfer in a single run(in total). The ODP.NET notes and materials I read never talk about keeping connection pooling off.
In dev, I keep the connection pooling off and it just works fine.
Is it advisable in the given scenario to keep the connection pooling off,(given all the connections are disposed properly after use)since:
It is a nightly job and there wont be much load on the Oracle server.
Connection Pooling might return stale connections, for which validate settings/exception handing needs to be done.
回答1:
The only reason for pooling is performance, so if your nightly job runs within it's window, there's nothing wrong with what you are doing, especially since it keeps your implementation simple by not having to worry about dead connections.
That said, I wouldn't make this standard practice. I rarely write code to handle stale connections and even then it's a simple factory. The question starts with why do you have stale connections at all? Typically this relates to either a firewall or a DBA job terminating idle connections, both of which should be changed or relaxed for an application account. Even in that case you can do the following:
- Specify Min Pool Size=0 in your connection string. Doing so lets ODP.net clean up even the last connection your app has, allowing your app to completely disconnect when it's idle for a long enough period.
- Specify a higher Decr Pool Size in your connection string. This will allow for more idle connections to be closed every 3 minutes by ODP.net.
- You could try setting Validate Connection = true - My guess would be there's less overhead validating the connection than there is with opening one.
More info can be found here: http://docs.oracle.com/cd/E15296_01/doc.111/e15167/featConnecting.htm#i1006228
来源：https://stackoverflow.com/questions/12662686/is-connection-pooling-a-must-have-in-odp-net