Connection pooling issue
Posted: Fri 12 Dec 2008 23:47
Currently we are evaluating UniDirect and I have to say it seems to get the job done right. However, I am having some issues with connection pooling that I would like to figure out.
We have a VS2005 code-generated dataset that I am testing with pgsql and sql server. The dataset resides on a multi-threaded server application and is behind a reader-writer lock. It is accessed mostly through queries on its table adapters.
I have the following problem with both sql server and pgsql:
1. With pooling enabled and default max pooled connections of 100:
Only the first 100 calls will go through before a pool timeout exception occurs. The code-generated table adapter code should(?) be closing the connections, returning them to the pool, but it is not.
2. To debug that, I tried the same with pooling disabled: I disable pooling in the connection string, however it behaves as if pooling is still enabled (same pooling timeout exception). I can change the max number of pooled connection even when pooling is disabled and the program behaves as if pooling is enabled with the new number for max pooled connections.
I might be doing something wrong that is causing 1), but not 2)... Any ideas?
We have a VS2005 code-generated dataset that I am testing with pgsql and sql server. The dataset resides on a multi-threaded server application and is behind a reader-writer lock. It is accessed mostly through queries on its table adapters.
I have the following problem with both sql server and pgsql:
1. With pooling enabled and default max pooled connections of 100:
Only the first 100 calls will go through before a pool timeout exception occurs. The code-generated table adapter code should(?) be closing the connections, returning them to the pool, but it is not.
2. To debug that, I tried the same with pooling disabled: I disable pooling in the connection string, however it behaves as if pooling is still enabled (same pooling timeout exception). I can change the max number of pooled connection even when pooling is disabled and the program behaves as if pooling is enabled with the new number for max pooled connections.
I might be doing something wrong that is causing 1), but not 2)... Any ideas?